Automated merge of renovate PR and release creation

[gberche-orange]

Model and current state

Target branch management mimics the organization of the upstream k3s repo https://github.com/k3s-io/k3s/branches

• master branch contains the actively maintained release (e.g 1.24.17)
  • renovate suggests bumps against the master branch
• latest back-port branches contain hot fixes to previous version potentially still in production (e.g. release-1.24.19)
  • renovate suggests bumps against the master branch
• available upstream branches (e.g. release-1.25 to release-1.28)
  • renovate suggests bumps against the master branch
• previous back-port branches (e.g. release-1.23) are stale, or deleted
  • renovate should ignore them

Creation of final bosh releases is idempotent

• triggered by commit on the branch
• if the bosh create-release --final results in git commits, then
  • the tag gets deleted and a new tag with same name gets created with the same commit message
    • Pb: this would trigger another noisy workflow for the updated tag
  • a new tag gets created

Branches and tags

• master
  • release tags 1.24.17+k3s1
• release-1.25
  • release tag
• release-1.26
  • release tag
• release-1.27
  • release tag
• release-1.28
  • release tag

Master branch contains the vendir.yaml targetting the current k3s version used in paas-templates.

Handling of new k3s patch versions

• Given a new k3s patch version is published
• When renovate contributes associated PR for such as
  • merged renovate PR 24 onto a branch forced pushed. renamed to not block new automerges #24 1.25.16
  • merged renovate PR 23 onto a branch forced pushed. renamed to not block new automerges #23 v1.25.16+k3s4
• And renovate auto-merges the PRs, see https://github.com/orange-cloudfoundry/k3s-packages-boshrelease/pulls?q=is%3Apr+is%3Aclose+label%3Amanager%2Fregex+is%3Amerged
• The this triggers the github workflow create-final-bosh-release (.github/workflows/create-final-bosh-release-on-commits.yml` ( which creates the vendors the upstream binary, upload the blobs
  • extract current version from vendir.yaml: v1.25.16+k3s4
  • creates the bosh final release, #42
  • commits the final release source files.
  • create a new tag based on the extracted version
  • generate the release note, linking the merged renovate PRs
    • overrides the release and any existing tag if already exists
  • uploads the tgz as a github release artifact

Branch management

New Branch creation

• Given a new k3s minor 1.29.x version is published in k3s repo
• When the weekly workflow create-release-branches(.github/workflows/create-release-branches.yml)
• Then a new release branche release-1.29 is created with fake version 1.29.0
• And renovate starts contributing PRs against this branch the real upstream version

PRs to compare against master

In order for branches to not diverge with master and only differ from vendir.yaml, PRs are created for each release branch, with the label k3s-base

Given a new release-1.29 branch is created

• When the create-PRs-based-on-release-branches workflow (.github/workflows/create-PRs.yml) trigger
• Then it automatically create a PR to ease tracking of divergences with master branch (in create-branch.bash)

TODO:

• test merging of release branch: test with a new 1.24

Rebase release branches against changes in master

• Given changes to master branch, e.g
  • renovate.json
  • .github/workflows (including github actions)
  • vendir.yaml (following merge of release-1.25 into master)
• Then renovate automatically rebases its branch and PRs
• Then the workflow rebase-release-branches-on-master-branch-commits(.github/workflows/rebase-release-branches-on-master-branch-commits.yml) automatically rebase other branches (may need to handle conflitcs on vendir.yaml)

Idempotence of artefacts w.r.t. release branch changes

• Given changes to release branch (say release-1.26)
  • on the following conditions
    • relevant to bosh release creation:
      • renovate auto merge of bump PRs k3s/kubectrl
    • irrelevant to bosh release creation:
      • renovate merge of unrelated dependency: github action bump
      • README.md change
      • scripts: create-branches.bash
  • The on-commit pipeline triggers
    • if the change is irrelevant to bosh release creation
      • it recreates the bosh final release with a new build id
    • otherwise, it skips the bosh release creation
      • e.g. skip commits not targeting bosh related directories
        • /.github
        • *.md
        • *.sh
      • only trigger on bosh related directories
    • and it does not update/override the github release and its artefacts

Given changes to release branch (say release-1.26)

• releases/k3s-packages/index.yml
• config/blobs.yml
• Then don't update master until the PR gets merged

Optimize hosting costs

Stop handling k8s versions that paas-templates is not using anymore. Once paas-templates

• stop asking renovate to find bumps on old releases
• stop building old releases
• test merge release-1.25 into master (to make sure this does not conflict or we know of to solve the conflicts automatically)
  • release-1.25 branch gets deleted. This prevents renovate from scanning it.

S3 bucket objects

• optimize size of blobs: k3s.tar.gz vs k3s.tar

Github release

• check coa is able to repackage from blobs
• if successful, remove the github release artefacts

Reusing workflows for other bosh package releases

• workflow to clear all state from repo/s3: clear S3 bucket objects, all blobs, all tags, all gh releases, all branches, all PRs ?
  • See https://github.com/orange-cloudfoundry/create-bosh-release-action
• avoid workflow duplication in among bosh package releases