diff --git a/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md b/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md index c2c94936..0dd798d8 100644 --- a/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md +++ b/pages/06.contribute/10.packaging_apps/80.resources/15.appresources/packaging_apps_resources.md @@ -7,7 +7,7 @@ routes: default: '/packaging_apps_resources' --- -Doc auto-generated by [this script](https://github.com/YunoHost/yunohost/blob/036119d9bad04545aeb2fb63eec20daf33a333fe/doc/generate_resource_doc.py) on 17/07/2023 (YunoHost version 11.2) +Doc auto-generated by [this script](https://github.com/YunoHost/yunohost/blob/f69f87fa6583cd42f74faf440dbdd13c0cb32257/doc/generate_resource_doc.py) on 17/07/2023 (YunoHost version 11.2) ---------------- @@ -225,11 +225,11 @@ Various options are available to accomodate the behavior according to the asset ```toml [resources.sources] -[resources.sources.main] -url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.tar.gz" -sha256 = "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" + [resources.sources.main] + url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.tar.gz" + sha256 = "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" -autoupdate.strategy = "latest_github_tag" + autoupdate.strategy = "latest_github_tag" ``` Or more complex examples with several element, including one with asset that depends on the arch @@ -237,25 +237,25 @@ Or more complex examples with several element, including one with asset that dep ```toml [resources.sources] -[resources.sources.main] -in_subdir = false -amd64.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.amd64.tar.gz" -amd64.sha256 = "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" -i386.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.386.tar.gz" -i386.sha256 = "53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3" -armhf.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.arm.tar.gz" -armhf.sha256 = "4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865" + [resources.sources.main] + in_subdir = false + amd64.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.amd64.tar.gz" + amd64.sha256 = "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" + i386.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.386.tar.gz" + i386.sha256 = "53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3" + armhf.url = "https://github.com/foo/bar/archive/refs/tags/v1.2.3.arm.tar.gz" + armhf.sha256 = "4355a46b19d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865" -autoupdate.strategy = "latest_github_release" -autoupdate.asset.amd64 = ".*\.amd64.tar.gz" -autoupdate.asset.i386 = ".*\.386.tar.gz" -autoupdate.asset.armhf = ".*\.arm.tar.gz" + autoupdate.strategy = "latest_github_release" + autoupdate.asset.amd64 = ".*\.amd64.tar.gz" + autoupdate.asset.i386 = ".*\.386.tar.gz" + autoupdate.asset.armhf = ".*\.arm.tar.gz" -[resources.sources.zblerg] -url = "https://zblerg.com/download/zblerg" -sha256 = "1121cfccd5913f0a63fec40a6ffd44ea64f9dc135c66634ba001d10bcf4302a2" -format = "script" -rename = "zblerg.sh" + [resources.sources.zblerg] + url = "https://zblerg.com/download/zblerg" + sha256 = "1121cfccd5913f0a63fec40a6ffd44ea64f9dc135c66634ba001d10bcf4302a2" + format = "script" + rename = "zblerg.sh" ``` @@ -263,14 +263,14 @@ rename = "zblerg.sh" - `prefetch` : `true` (default) or `false`, wether or not to pre-fetch this asset during the provisioning phase of the resource. If several arch-dependent url are provided, YunoHost will only prefetch the one for the current system architecture. - `url` : the asset's URL -- If the asset's URL depend on the architecture, you may instead provide `amd64.url`, `i386.url`, `armhf.url` and `arm64.url` (depending on what architectures are supported), using the same `dpkg --print-architecture` nomenclature as for the supported architecture key in the manifest + - If the asset's URL depend on the architecture, you may instead provide `amd64.url`, `i386.url`, `armhf.url` and `arm64.url` (depending on what architectures are supported), using the same `dpkg --print-architecture` nomenclature as for the supported architecture key in the manifest - `sha256` : the asset's sha256sum. This is used both as an integrity check, and as a layer of security to protect against malicious actors which could have injected malicious code inside the asset... -- Same as `url` : if the asset's URL depend on the architecture, you may instead provide `amd64.sha256`, `i386.sha256`, ... + - Same as `url` : if the asset's URL depend on the architecture, you may instead provide `amd64.sha256`, `i386.sha256`, ... - `format` : The "format" of the asset. It is typically automatically guessed from the extension of the URL (or the mention of "tarball", "zipball" in the URL), but can be set explicitly: -- `tar.gz`, `tar.xz`, `tar.bz2` : will use `tar` to extract the archive -- `zip` : will use `unzip` to extract the archive -- `docker` : useful to extract files from an already-built docker image (instead of rebuilding them locally). Will use `docker-image-extract` -- `whatever`: whatever arbitrary value, not really meaningful except to imply that the file won't be extracted (eg because it's a .deb to be manually installed with dpkg/apt, or a script, or ...) + - `tar.gz`, `tar.xz`, `tar.bz2` : will use `tar` to extract the archive + - `zip` : will use `unzip` to extract the archive + - `docker` : useful to extract files from an already-built docker image (instead of rebuilding them locally). Will use `docker-image-extract` + - `whatever`: whatever arbitrary value, not really meaningful except to imply that the file won't be extracted (eg because it's a .deb to be manually installed with dpkg/apt, or a script, or ...) - `in_subdir`: `true` (default) or `false`, depending on if there's an intermediate subdir in the archive before accessing the actual files. Can also be `N` (an integer) to handle special cases where there's `N` level of subdir to get rid of to actually access the files - `extract` : `true` or `false`. Defaults to `true` for archives such as `zip`, `tar.gz`, `tar.bz2`, ... Or defaults to `false` when `format` is not something that should be extracted. When `extract = false`, the file will only be `mv`ed to the location, possibly renamed using the `rename` value - `rename`: some string like `whatever_your_want`, to be used for convenience when `extract` is `false` and the default name of the file is not practical @@ -287,8 +287,8 @@ The script will rely on the code repo specified in the upstream section of the m `autoupdate.strategy` is expected to be one of : - `latest_github_tag` : look for the latest tag (by sorting tags and finding the "largest" version). Then using the corresponding tar.gz url. Tags containing `rc`, `beta`, `alpha`, `start` are ignored, and actually any tag which doesn't look like `x.y.z` or `vx.y.z` - `latest_github_release` : similar to `latest_github_tags`, but starting from the list of releases. Pre- or draft releases are ignored. Releases may have assets attached to them, in which case you can define: -- `autoupdate.asset = "some regex"` (when there's only one asset to use). The regex is used to find the appropriate asset among the list of all assets -- or several `autoupdate.asset.$arch = "some_regex"` (when the asset is arch-specific). The regex is used to find the appropriate asset for the specific arch among the list of assets + - `autoupdate.asset = "some regex"` (when there's only one asset to use). The regex is used to find the appropriate asset among the list of all assets + - or several `autoupdate.asset.$arch = "some_regex"` (when the asset is arch-specific). The regex is used to find the appropriate asset for the specific arch among the list of assets - `latest_github_commit` : will use the latest commit on github, and the corresponding tarball. If this is used for the 'main' source, it will also assume that the version is YYYY.MM.DD corresponding to the date of the commit. It is also possible to define `autoupdate.upstream` to use a different Git(hub) repository instead of the code repository from the upstream section of the manifest. This can be useful when, for example, the app uses other assets such as plugin from a different repository.