action: download latest version of apk#4364
Conversation
This uses the gitlab API to fetch the latest release of apk from the upstream apk-tools repo, instead of hardcoding a version. Since gitlab API can be flaky, I put it in a retry loop. set -x in a subshell in the loop because you can never have too much info if/when things break. I also made the whole thing non-fatal if it still fails to get apk after retrying, because not all of them need apk (even if it means other later jobs using apk might fail). I added a warning for that situation so hopefully it makes it a bit more obvious why a later job using apk might fail if that was the case.
| sudo curl -fsSL --retry 5 --retry-all-errors -o /usr/bin/apk "$APK_TOOLS_API/packages/generic/${APK_VERSION}/x86_64/apk.static" | ||
| echo "${APK_SHA256} /usr/bin/apk" | sha256sum --check | ||
| sudo chmod +x /usr/bin/apk | ||
| ) || echo "WARNING: Failed to fetch latest apk!" |
There was a problem hiding this comment.
I really don't like ignoring errors in workflows and tests, it makes things unpredictable and unnecessarily hard. It hasn't hurt us much before, so the simplest way would be to just keep the previous "must succeed" behaviour. Alternatively, this could introduce an option whether to install apk, and for backwards compatibility it could default to on. Then users can switch it off to skip the step if they don't need apk.
There was a problem hiding this comment.
I think hardcoding the current version as baseline might be fine.
| set -ex | ||
| APK_TOOLS_API="https://gitlab.alpinelinux.org/api/v4/projects/5" | ||
| APK_VERSION=$(curl -fsSL --retry 5 --retry-all-errors "$APK_TOOLS_API/repository/tags?per_page=1" | jq -r '.[0].name') | ||
| APK_PKG_ID=$(curl -fsSL --retry 5 --retry-all-errors "$APK_TOOLS_API/packages?package_name=${APK_VERSION}&package_type=generic" | jq '.[] | select(.version == "x86_64") | .id') |
There was a problem hiding this comment.
While testing this out this returned two lines for me, you probably want to ensure that only the latest pkg ID wins.
| ( | ||
| set -ex | ||
| APK_TOOLS_API="https://gitlab.alpinelinux.org/api/v4/projects/5" | ||
| APK_VERSION=$(curl -fsSL --retry 5 --retry-all-errors "$APK_TOOLS_API/repository/tags?per_page=1" | jq -r '.[0].name') |
There was a problem hiding this comment.
I'm not sure what the GitLab API guarantees here, but the endpoint returns also rc releases and in between the v3.0.0 rc releases there was v2.14.10, so I don't assume any sorting.
Maybe something like this will do
| APK_VERSION=$(curl -fsSL --retry 5 --retry-all-errors "$APK_TOOLS_API/repository/tags?per_page=1" | jq -r '.[0].name') | |
| APK_VERSION=$(curl -fsSL --retry 5 --retry-all-errors "$APK_TOOLS_API/repository/tags?per_page=1" | jq -r '.[].name' | sort -V | tail -1) |
| sudo curl -fsSL --retry 5 --retry-all-errors -o /usr/bin/apk "$APK_TOOLS_API/packages/generic/${APK_VERSION}/x86_64/apk.static" | ||
| echo "${APK_SHA256} /usr/bin/apk" | sha256sum --check | ||
| sudo chmod +x /usr/bin/apk | ||
| ) || echo "WARNING: Failed to fetch latest apk!" |
There was a problem hiding this comment.
I think hardcoding the current version as baseline might be fine.
3 participants
This uses the gitlab API to fetch the latest release of apk from the upstream apk-tools repo, instead of hardcoding a version.
Since gitlab API can be flaky, I put it in a retry loop. set -x in a subshell in the loop because you can never have too much info if/when things break. I also made the whole thing non-fatal if it still fails to get apk after retrying, because not all of them need apk (even if it means other later jobs using apk might fail). I added a warning for that situation so hopefully it makes it a bit more obvious why a later job using apk might fail if that was the case.