This runs 'kconfig generate' for all archs that the generic kernels
support in order to make sure that kconfig-generic.toml changes are
valid for everything for the kernels it would apply to. This is meant
to catch kconfig changes that might introduce options that don't exist
on some kernel/arch combos or that might be missing other kconfig
dependencies.
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9250>
Previously, kconfigcheck would only run if the kernel configs of a
kernel package where changed. This means that, if a kernel package
is not directly upgraded, the kernel config will most likely never
be touched, leading to extremely out-of-date kernel configs.
Checking when the APKBUILD is modified instead would force the
check at every modification of a kernel package, forcing more
up-to-date configs.
Signed-off-by: Aster Boese <asterboese@mailbox.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8923>
I was wondering why apkbuild-lint found a bug locally but not in CI:
IC[AL65]:main/postmarketos-ui-phosh/APKBUILD:66:2:non-local 'install' variable in function 'openrc'. Add install scripts to global install variable instead.
The reason is that the we use alpine:latest here. Let's change it to
alpine:edge so we have the most recent abuild-go version that finds the
most APKBUILD linting bugs.
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8735>
While ideally everyone would be running the latest pmbootstrap version,
in practice people don't always update right away. And even if they want
to, their distribution may not have the latest version packaged yet.
Let's enforce some wiggle room here so distributions have time to catch
up before we require newer versions.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8550>
The package auto-update runs in a scheduled pipeline, it should be
the only job that runs however a discrepency in the rules for the
deploy-docs job results in it running as well.
To mitigate this, add an additional rule to never run the job in a
scheduled pipeline.
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7457>
It is a lot more prone to breaking than stable, which is the
default. The reason to have them there is also not very clear.
The editor-config has been there since its introduction in
e7a8141113. It might be that at the time
it was not in community or in a stable release. The shellcheck-grep
has been there since 81872a59c1, which
was already 6 years ago. Probably at the time our tooling was a lot
less integrated and stable in alpine as it is today, and everything
was running edge.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6471
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>
Introduce some basic infrastructure to allow running per-package unit
test jobs, as well as a library to support unit-testing shell scripts.
Packages can provide their own unit tests by adding a tests/
subdirectory to the package, this should contain a .gitlab-ci.yml file
with jobs that extend the .package-test job template as well as any
supporting data and scripts.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6182
We now have a bot that reads those lines from APKBUILD files, instead
of using a proprietary gitlab feature. Relevant changes:
* Change @ollieparanoid for @Newbyte as maintainer for GNOME packages
where Oliver was listed.
* Don't add @craftyguy as Librem5 maintainer, as he dropped it long
ago
* Remove entries referencing archived ports
* Don't touch jenneron's maintainership. That's a task for another day
* Don't add "balejk" as maintainer. We have tried pinging them, but
seem to be currently idle
person is. Help figuring it out would be welcomed.
* Don't add "binarycraft" as maintainer. Last contribution was years
ago: https://gitlab.com/binarycraft
* Don't add more maintainers to linux-postmarketos-qcom-msm8953, as it
would have ended up with 7, which might be a bit too much
* Don't add more maintainers to the PinePhone. The current ones seem
to actually be the most active
* Don't add Danct12 to N900. Sicelo has been single-handedly managing
it for a long while
* Update maintainer emails for Nikita Travkin, Alexey Minnekhanov, and
Barnabás Czémán
[ci:skip-vercheck] Co-Maintainer changes require no pkgrel updates
since the names do not make it to the package itself
[ci:ignore-count]
Fixes#3530
[ci:skip-build]: already built successfully in CI
When enabling new options in kconfigcheck, it's likely that some kernels
in pmaports will fail, but often undesirable to rebuild all the kernels
particularly when the options being enabled are for quality of life.
Adjust the rules for the kconfig check job in CI so that it will fail
with a warning in this case, but still fail with an error when an
updated kernel package doesn't pass.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
[ci:skip-build]: already built successfully in CI
We haven't had kernels in main/ for soon three years[1], so no need
to bother checking this location.
[1]: See commits 47d8f823..8f24fe3a
[ci:skip-build]: already built successfully in CI
Technically this option can be configured in the Gitlab UI, but I spent
about 3 hours debugging a CI failure caused by it being too low and
I don't want to risk forgetting this can happen later if/when someone
decides to lower it in the UI. By setting it here, we can have some
context/history about why.
This fixes the CI in !5688
Also see:
https://docs.gitlab.com/17.4/ee/user/project/repository/monorepos/index.html#shallow-cloning
[ci:skip-build]: already built successfully in CI
Since we build linux-next before pushing to BPO, use the big runner so
we don't delay the update by hours. BPO needs to build it *again* too...
would be nice if we could push the artifact directly, ah well.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
We have access to the fancy runners since GitLab.com donate premium to
us. There's no downside to making the most of them while we can. We
don't depend on them, but they'll make our CI go zoom!
For the next few months until we migrate to self-hosted :D
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Introduce support for having CI automatically update packages using
project access tokens and scheduled pipelines.
The pipeline schedule is configured with an additional variable
containing a list of packages to update, the autoupdate-fetch.sh script
then calls a handler for each of these, the handler is expected to check
for an update, make the necessary APKBUILD changes and commit them.
After all packages have been updated, the changes are pushed to pmaports
master using a project access token.
[ci:skip-build] takes too long to build in CI
Pablo Correa Gómez