Skip to content

[RFE] Make CI and Release tooling more declarative #193

Open
@djzager

Description

@djzager

There are some problems that we currently run into with our Github Actions based CI/CD release tooling:

  1. Some workflows like image building, issue reconciling, cherry picking have to exist all repositories. This creates a burden when new repositories are added under the Konveyor umbrella or when one of those workflows needs to be modified.
  2. Not all repositories produce container images as their release artifact. Instead they are git cloned into other container images.
  3. It's very easy for container images to become out of sync. A concrete example is that the analyzer-lsp container image needs jdtls-server-base. Changes to jdtl-server-base SHOULD cause analyzer-lsp to be rebuilt.
  4. https://github.com/konveyor/operator/blob/main/.github/workflows/create-release.yml relies on waiting for images to exist which causes problems when a release pipeline publishes more than 1 image.
  5. Cleaning up failed repo releases + tags + container images is manual process

The aim of this work would be to improve the CI and Release Tooling, provide a single source of truth, and push CI/CD release tooling updates to our project repositories more automated.

Tasklist based on the enhancement described in #201.

### Tasks
- [ ] Update config.yaml in release tools to reflect dependency relationships between components of Konveyor. This will require an update to the config types.
- [ ] Generate release pipeline from config.yaml. When this work is complete the release pipeline for main, and releases going forward, will be in the release-tools repository.
- [ ] Move every Konveyor repositories CI checks to use `konveyor/ci/.github/workflows/global-ci-bundle.yml`. Should seriously consider automation to enforce this on all konveyor repositories (ie. every component should have PR checks to make sure the PR doesn't break CI).
- [ ] Need a reusable action or step on CI failure for nightlies that takes all of the images from a run, mirrors them to quay + tags and pins them by SHA + collects them into a bundle and informs the failure notification how an engineer could recreate the failed build.
- [ ] ...

Metadata

Metadata

Assignees

Labels

kind/designCategorizes issue or PR as related to design.priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release.triage/acceptedIndicates an issue or PR is ready to be actively worked on.

Type

No type

Projects

Status

🆕 New

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions