1. 06 May, 2021 7 commits
  2. 05 May, 2021 3 commits
    • Alexander Wellbrock's avatar
      fix job rules:if · 4056d070
      Alexander Wellbrock authored
      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
    • Alexander Wellbrock's avatar
      Revert "templates: reverse the if include to if exclude" · 1df3e8ab
      Alexander Wellbrock authored
      This reverts commit 641bef75.
    • Alexander Wellbrock's avatar
      templates: reverse the if include to if exclude · 641bef75
      Alexander Wellbrock authored
      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.
  3. 04 May, 2021 2 commits
  4. 03 May, 2021 5 commits
    • Alexander Wellbrock's avatar
      fix missing quotes on if statement · 760ff8e0
      Alexander Wellbrock authored
    • Alexander Wellbrock's avatar
      fix regex expression in job filters · a9a7197c
      Alexander Wellbrock authored
    • Alexander Wellbrock's avatar
      prep release v0.4.1 · c12a6d63
      Alexander Wellbrock authored
    • Alexander Wellbrock's avatar
      Make jobs selectable · fda23913
      Alexander Wellbrock authored
      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.
    • Alexander Wellbrock's avatar
      Change job dependency on protected branches · 7455f1ea
      Alexander Wellbrock authored
      Most jobs now require a protected environment since they usually handle
      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.
  5. 23 Apr, 2021 8 commits
  6. 14 Apr, 2021 7 commits
  7. 13 Apr, 2021 3 commits
  8. 10 Apr, 2021 3 commits
  9. 09 Apr, 2021 2 commits
    • Alexander Wellbrock's avatar
      prep version 0.4.0 · 2d5cb413
      Alexander Wellbrock authored
      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.
    • Alexander Wellbrock's avatar