The recent change to make CI pipeline build test images on a manual
trigger masks the outcome of the pipeline. Let's use the new inputs [1]
feature to allow manually triggering the pipeline with an explicitly
built image instead.
[1] https://docs.gitlab.com/ci/inputs/
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
We rely on a hack that avoids compressing and pushing the cache if it
has not really changed but it's worth adding links.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1695
Approved-by: Ryan Lee <rlee287@yahoo.com>
Approved-by: Georgia Garcia <georgia.garcia@canonical.com>
Merged-by: Georgia Garcia <georgia.garcia@canonical.com>
We rely on a hack that avoids compressing and pushing the cache if it
has not really changed but it's worth adding links.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
The current logic will only build spread images, for master (which uses
protected cache), when the .image-garden.mk or .gitlab-ci.yml files
change as compared to master. This is great IF they change and WHEN the
cache is hot but right now it seems that this is not the case and master
just has no protected cache.
Add a manual knob to run the one-off cache job whenever we want to.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This relies on a documented hack that makes GitLab cache machinery
skip the upload if all of the cached files are missing in the tree.
This saves about a minute per pull request CI/CD run times the number of
images required for testing.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1691
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This fixes the long standing issue affecting caching of the image
between the image-* jobs and the spread-* jobs.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1690
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
This relies on a documented hack that makes GitLab cache machinery
skip the upload if all of the cached files are missing in the tree.
This saves about a minute per pull request CI/CD run times the number of
images required for testing.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This fixes the long standing issue affecting caching of the image
between the image-* jobs and the spread-* jobs.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This way they can be automatically cancelled by GitLab when a new commit is pushed
to a merge request, this providing feedback to the tip of the branch or pull request
more rapidly.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This requires a runner with the tags: linux, x86_64, kvm. One needs to
be provisioned for the AppArmor project for the pipeline to function.
It is possible to run the same tests on SAAS runners offered by GitLab
but due to issue gitlab-org/gitlab-runner#6208 there is no way to expose
/dev/kvm on the host to the guest. Without this feature emulation works
but is rather slow as to be impractical.
Note that there's some overlap between the build-all job and spread that
might be avoided in the future. At present this is made more difficult
by the fact that the path where build-all job builds libapparmor is
stored internally by autotools. This prevents us from using GitLab
artifacts from moving the built files across to the spread testing jobs
without extra work.
In addition to adding the spread job, remove test-build-regression job.
This job is now redundant since the same operation is done when spread
builds and runs regression tests.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1512
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
We were not building or caching the .seed.iso target, causing make to re-create
the image, as seen in the make --debug --dry-run output:
```
Updating goal targets....
File ubuntu-cloud-24.04.user-data does not exist.
Must remake target ubuntu-cloud-24.04.user-data.
echo "${USER_DATA}" | tee ubuntu-cloud-24.04.user-data
Successfully remade target file ubuntu-cloud-24.04.user-data.
File ubuntu-cloud-24.04.meta-data does not exist.
Must remake target ubuntu-cloud-24.04.meta-data.
echo "${META_DATA}" | tee ubuntu-cloud-24.04.meta-data
Successfully remade target file ubuntu-cloud-24.04.meta-data.
Prerequisite ubuntu-cloud-24.04.user-data is newer than target ubuntu-cloud-24.04.seed.iso.
Prerequisite ubuntu-cloud-24.04.meta-data is newer than target ubuntu-cloud-24.04.seed.iso.
Must remake target ubuntu-cloud-24.04.seed.iso.
/usr/bin/genisoimage \
-input-charset utf-8 \
-output ubuntu-cloud-24.04.seed.iso \
-volid CIDATA \
-joliet \
-rock \
-graft-points \
user-data=ubuntu-cloud-24.04.user-data \
meta-data=ubuntu-cloud-24.04.meta-data
Successfully remade target file ubuntu-cloud-24.04.seed.iso.
Prerequisite ubuntu-cloud-24.04.seed.iso is newer than target ubuntu-cloud-24.04.x86_64.qcow2.
```
Build and cache the cloud-init seed iso to prevent that.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
We are seeing images cached and then re-constructed as if something had
changed in the meanitime. Debug image construction with make --dry-run --debug.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This way there's somewhat less repetition and the flow of job definitions is,
at least to me, easier to read.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
Our cache is rather compressed already, so this should help
a little with wall-clock time.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
A new explicit, non-parallel job is injected when the .image-garden.mk or
.spread.yaml file changes. This job warms up the cache for the subsequent
parallel testing jobs.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
As a security measure, GitLab splits cache into two broad pools: protected and
non-protected. Any job running in a protected branch has access to the
protected cache pool. All other jobs run in the non-protected cache pool.
This effectively forces us to push to cache in non-protected branches, like all
the merge requests, in order to actually use the cache.
Ideally we'd disable this protection and only push from the default branch and
pull otherwise, as changes to dependency set is rather rare.
[1] https://docs.gitlab.com/ee/ci/caching/#use-the-same-cache-for-all-branches
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This job is now redundant since the same operation is done when spread
builds and runs regression tests.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
This requires a runner with the tags: linux, x86_64, kvm. One needs to
be provisioned for the AppArmor project for the pipeline to function.
It is possible to run the same tests on SAAS runners offered by GitLab
but due to issue gitlab-org/gitlab-runner#6208 there is no way to expose
/dev/kvm on the host to the guest. Without this feature emulation works
but is rather slow as to be impractical.
Note that there's some overlap between the build-all job and spread that
might be avoided in the future. At present this is made more difficult
by the fact that the path where build-all job builds libapparmor is
stored internally by autotools. This prevents us from using GitLab
artifacts from moving the built files across to the spread testing jobs
without extra work.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
We now have GitLab CI/CD pipeline co-existing with spread, coupled with
image-garden and the cloud-init profile defined for each distribution.
To avoid duplicating list of required dependencies, re-use cloud-init
profile as the reference list of dependencies (superset between build
and test) to install.
In addition to the dependency list, the build_all job now re-uses spread
prepare section in similar fashion. If it builds in spread, it should
build in CI as well.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
There is no other use of this yaml fragment in the project so inline it
for simplicity.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
The "only" feature has been deprecated for a while. The standard
replacement is the rules:if feature.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
The artifact restoration step does not preserve mtime, resulting in source files newer than built files, resulting in a needless rebuild of everything before actually running the tests.
Signed-off-by: Ryan Lee <ryan.lee@canonical.com>
This pipeline only makes sense to run in the upstream project where
the coverity variables are defined, so they currently fail in forks.
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
In the course of preparing !1207, I found that the validation rules in `profiles/Makefile` did not take kindly to the new `profiles/apparmor/profiles/extras/abstractions/` directory. I tried a couple rounds of quick fixes, but it became clear that the rules as currently written were just not amenable to the new addition, and needed more attention than I could give it by-the-by.
So I separated out that commit, and revised the makefile more thoroughly. The updated rules now rely more on `find(1)` than `$(wildcard)`, and have a number of [what I believe to be] small quality-of-life improvements. Taken together, `make check` passes cleanly with the new files from my other MR present.
One thing I noticed was that the profiles under `apparmor.d/` were not previously being checked for the `include if exists <local/*>` bit---only the ones under `extras/`. I've thus included a fix to the `sbuild-shell` profile, which fortunately was the only one that failed the check.
Note that at present, you'll get a couple of harmless `find: ‘./apparmor/profiles/extras/abstractions’: No such file or directory` errors when running the checks, since that directory won't appear until the other MR is merged. I figure, better to bear that for now, and not have to touch the makefile again later.
NOTE: The CI pipeline here will need to be updated to invoke the `check-local` target instead of `check-extras`. This target was renamed as it is no longer limited in scope to the profiles under `extras/`.
MR: https://gitlab.com/apparmor/apparmor/-/merge_requests/1214
Approved-by: John Johansen <john@jjmx.net>
Merged-by: John Johansen <john@jjmx.net>
The following exceptions were added to flake8 since they have several
expected uses in the tools and their tests:
E501: Line lengths are recommended to be no greater than 79 characters.
E241: Multiple spaces after ','
W503: Line break occurred before a binary operator
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Since we are using ubuntu:latest, and noble was released, some tests
are failing.
shellcheck needs python3 to run, which was possibly installed by
default in previous ubuntu images and is no longer the case.
Ignore dist-packages python files during our coverage tests.
Fixes: https://gitlab.com/apparmor/apparmor/-/issues/388
Signed-off-by: Georgia Garcia <georgia.garcia@canonical.com>
Rename the "check-extras" target to "check-local" as it is no longer
limited to the extra profiles, and also fix a local include in the
sbuild-shell profile so that it passes the newly-applied CI check.
... so that each change in master gets scanned (until we reach the scan
limit).
This will give us more timely results than only scanning the coverity
branch whenever someone manually updates it.
Unfortunately secret detection is failing with
fatal: error in object: unshallow sha1
and blocking merge requests. Unfortuntely all suggested work arounds
from https://gitlab.com/gitlab-org/gitlab/-/issues/351976 failed to
work.
Signed-off-by: John Johansen <john.johansen@canonical.com>
It reports hundreds of issues, lots of them with critical severity.
The GitLab UI allows dismissing them one-by-one very quickly,
but I'm not a good person to do that.
Let's try to have a better signal/noise ratio for this first iteration.
According to
https://docs.gitlab.com/ee/user/application_security/dependency_scanning/,
"dependency scanning lets you know if your application uses an external (open
source) library that is known to be vulnerable".
AppArmor is not the kind of project that benefits from it: we don't link
statically against our dependencies, nor bundle them into released
artifacts.
