Fix that the build-jobs were using Alpine edge. This seems
unintentional, or at least inconsistent. Before this patch we had:
$ git grep alpine:latest
.ci/build-jobs.yaml.j2:image: registry.alpinelinux.org/img/alpine:latest
.gitlab-ci.yml:image: alpine:latest
It turns out that "registry.alpinelinux.org/img/alpine:latest" is
actually alpine edge:
$ docker run --rm registry.alpinelinux.org/img/alpine:latest cat /etc/os-release
Unable to find image 'registry.alpinelinux.org/img/alpine:latest' locally
latest: Pulling from img/alpine
d4a983187cfd: Pull complete
Digest: sha256:47b4a945203d4bad4e0c7840d64044da50a719d0cd0512a50e3ab473240635ea
Status: Downloaded newer image for registry.alpinelinux.org/img/alpine:latest
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.21.0_alpha20240923
PRETTY_NAME="Alpine Linux edge"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
And alpine:latest is stable (when fetched from docker hub, with podman
it could be configured to point at alpine's registry as well, which
means it is edge... but the OSUOSL CI runners use docker):
$ docker run --rm alpine:latest cat /etc/os-release
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
589002ba0eae: Already exists
Digest: sha256:25109184c71bdad752c8312a8623239686a9a2071e8825f20acb8f2198c3f659
Status: Downloaded newer image for alpine:latest
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.23.3
PRETTY_NAME="Alpine Linux v3.23"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
Using stable makes more sense here, so temporary bugs in edge don't
break our CI. It is currently somewhat broken because running
pmbootstrap with python 3.14 and musl results in crashes with "No file
descriptors available" errors in some situations.
Related: https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/work_items/141
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8340>
Only Alpine kernels use the vmlinuz-VARIANT naming scheme, postmarketOS
kernel images are always called vmlinuz.
Since we only use our own kernels now, we can completely get rid of the
variable and always look for vmlinuz.
[ci:skip-vercheck]: the checks can't handle bumping pkgver *and* pkgrel
[ci:skip-build]: takes a long time and already built successfully in CI
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7398>
The check in Python did not work with devices without kernel variants
due to it returning None and that breaking the has_kernel_variants
check. Fix that, and also adding the kernel variant to install
packages, which was missed. In the process, rename kernels to
kernel_variants. All devices have at least one kernel, but not all
have "variants" :)
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7489>
This sounds counter-productive and counter-intuitive, but hear me out:
this allows using `needs` to depend on those jobs, without further
templating downstream jobs.
In turn, those jobs depending on a disabled jobs, while they still exist
in the “graph” of the pipeline, are also transitively disabled.
This change, for all intents and purpose, is a no-op regarding the
amounts of jobs being sent to CI runners.
Also updates the comment for the placeholder job, since the wording
could lead to think that *having jobs* is sufficient. In reality, having
jobs that ran succesfully is necessary for the child pipeline to be
successful.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6399
Following Alpine's example. This allows some optimizations:
* Don't start one job per architecture simply to skip them after
rebase and before merge
* If there are no packages, don't start the jobs at all (not true,
gitlab bug)
* Avoid creating jobs for architectures that don't have changed
packages, thus further reducing the unnecessary
jobs and possibly reducing transient failures
Co-authored-by: Clayton Craft <clayton@craftyguy.net>
Aelin