GitLab

The naive reliance on a protected-branch check was not good enough.
We'll now check in a more general manner if the storage directory
exists and if the

The if statement has to be a combined if and also the variable needs to
be exposed to the jobs so they can use it. This is not ideal, we'll have
to come up with a better way of doing this.

Before the jobs would be excluded per default and only added if a rule
matches. That's how Gitlab CI rules:if works. In terms of the image job
this would mean that the include rule would always add the job to the
pipeline.

This reverts commit 641bef75.

The include rule seems not to work as intended. Let's reverse it to a
rule that will exclude jobs if stated so explicitely and otherwise
handle includes with known rule sets.

The scripts currently only checks shell syntax. I forgot often
enough.

The different jobs are now selectable via the CI_INCLUDE_JOBS variable.
This variable is pre-filled with all jobs currently available, so no
changes to existing pipelines should be necessary.

Most jobs now require a protected environment since they usually handle
secrets.

Also the mount.sh script is renamed to ci-prepare, as that is more fitting.

The ci-prepare job now creates an empty rpm-ostree repository on the
container mount location if not executed in a protected environment.
This is done so the build job can still be executed as a baseline in
non-protected environments.

This will certainly change soon enough as automated, virtualization tests
become a thing since we want to give the opportunity to execute them on
any branch eventually. Most probably with at least the ability to specify
an rpm-ostree remote as alternative read-only source. Maybe we have to
restructure the pipeline such that a build is done in a temporary cache
repository that is then used to run tests and only if those tests succeed
is the commit / ref added / published / updated at the remote. The image
should then be build from the live remote, although an image build for
test result could be useful for manual tests and QA. In that case we
could define subsequent jobs like the publish as manual, after tests
and test-image have been reviewed.

Add automated GPG signatures

See merge request !5

Apparently the gpg signature is applied to the summary, not to the
delta. The delta is signed using ed25519 instead for a different purpose.

Allow setting a different source branch, necessary for upgrades.

The template will now use a generic build options variable.

BREAKING: the following pre-existing options now have to be added to
the generic options variable:

--treecompose
--ostree-files
--spec

Incorporates logic to decide if deltas can be build or not.

This will save approx. 15- 25 minutes of runtime. These jobs are not
relevant to execute on all pipelines.

The delta build job only works with two consecutive commits.

In CI tests we also need to specify the branch.

This should be use-case dependant.

Feature: (automated) gpg signatures

See merge request !4

Major new feature is the signature job and signing in the build job.

Many different scenarios are possible:

Use the gitlab CI variables to directly sign commits in the build job.
Depending on how variables are configured this will sign all branches.
To restrict the branches you one can make them only available in
protected branches.

Another method is to use the sign job. This job can then be extended
with rules to e.g. only run on branches distinct from the main branch,
because you'd like to sign commits on main branch manually with a
different more secure key. Or only execute the job on protected branches.

Apart from gitlab CI variables the GPG credentials might also be
provided fully or partially through the gitlab-runner. With the runners
env configuration it can override or add the credentials on the fly.
The benefit with this is that you can distribute e.g. the key and it's
passphrase through different machines with different access levels.
This way someone with access to the gitlab repo will not automatically
gain acccess on the full gpg creds. Keep in mind that a runner
configured like that is now confidential and that all jobs could leak
the GPG key or passphrase.