Bundle image nightly build with limitador lastcommit

[eguzki]

WHAT

This is an alternative approach to get the latest operand (limitador), instead of relying on org var ${{ vars.LIMITADOR_SHA }}.

The operator is being built nightly basis, that does not change. Additionally, the operator is being build on any push to any branch (including main). That applies for the operator image, the bundle image and the catalog (index) image.

Bundle/Catalog builds from branches (including main) will have a reference to quay.io/kuadrant/limitador:latest

Nightly builds will have a tag with the format nightly-{date}, for example: nightly-04-09-2024. Additionally, the nightly builds will push nightly-latest tag with the same manifest digest.

Bundle/Catalog nightly builds will have a reference to quay.io/kuadrant/limitador:{LATEST_COMMIT}, being LATEST_COMMIT, the git revision of the HEAD of main at the build time.

The workflow includes a check to verify that the docker image exists. It fails otherwise. It can be improved to retry N time before failing. Left for future improvement. This https://github.com/marketplace/actions/retry-action could be used for that.

The {operator image, bundle, catalog} images being built from a push to main will still generate image tag with the git sha of the limitador operator repo used to build it. For example: quay.io/kuadrant/limitador-operator-bundle:8d7e9ed9f550e7bb105b733f5de04ece964ecc72. It is left for compatibility with the current way of building the kuadrant operator. However, limitador operator bundle for a git sha for it's own repo is conceptually wrong (or maybe meaningless). It would be correct and useful if we would commit in the operator's repo every time the operand (limitador) changed the HEAD of main. However we are not doing that. Thus, for the same limitador operator git revision, there could be infinite different bundles, one per each operands (limitador) revision. In order to fix this, the approach is the nightly build picking the latest revision of the operand. Whenever the operator or the operand changes the HEAD, the nightly build will put both HEADS together into a bundle that QE can test.

Release builds should not be affected as it is all pinned to a version.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.50%. Comparing base (8d7e9ed) to head (cf1d16b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #156      +/-   ##
==========================================
+ Coverage   84.00%   84.50%   +0.50%     
==========================================
  Files          19       19              
  Lines         994      994              
==========================================
+ Hits          835      840       +5     
+ Misses        102       99       -3     
+ Partials       57       55       -2     

Flag	Coverage Δ
integration	78.47% <ø> (+0.50%)	⬆️
unit	66.51% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
api/v1alpha1 (u)	100.00% <ø> (ø)
pkg/helpers (u)	83.87% <ø> (ø)
pkg/log (u)	94.73% <ø> (ø)
pkg/reconcilers (u)	74.67% <ø> (ø)
pkg/limitador (u)	98.11% <ø> (ø)
controllers (i)	73.66% <ø> (+1.66%)	⬆️
pkg/upgrades	88.88% <ø> (ø)

see 1 file with indirect coverage changes

[eguzki]

Would love your feedback @didierofrivia

cc @guicassolato

[eguzki]

@didierofrivia whenever you have a change to look at this, please review

[didierofrivia]

I like the idea of not relying on stored variables, but one comment only, how do you make sure LATEST_COMMIT is already built and pushed to quay.io ? That's the only reason the current implementation is relying on quay to get the "latest SHA"

[eguzki]

how do you make sure LATEST_COMMIT is already built and pushed to quay.io ?

There is an specific check for that

The workflow includes a check to verify that the docker image exists. It fails otherwise. It can be improved to retry N time before failing. Left for future improvement. This https://github.com/marketplace/actions/retry-action could be used for that.

[didierofrivia]

Thanks @eguzki, missed that piece hehe. Thing now is, if it fails, there's no guarantee it will ever be there, even if it retries N times. For Kuadrant Operator this would be kind of problematic, since it relies on many dependencies that need to be there before bundling. If there's a way we can mitigate that, then it's great.

[eguzki]

For kuadrant operator, my idea is that the operator will not need to find out versions of the dependencies. It will try to build bundle and catalog based on nightly "well known" tags, i.e. nightly-04-09-2024. That being said, if the deps does not exist or have not being pushed yet, (after some retries), the nightly would fail. I think we can afford that. Assuming that usually nightly builds are built successfully, a error from time to time is not a big deal for me. And if it is really needed, it can always be built manually.

I think it is better to have a well known bundle / catalog build that can fail, that a bundle / catalog build with references to unexpected builds that never fail.

In order to mitigate build failures, we need some kind of sync system. A pipeline that defines a workflow: first A is been built, then B is been built and can rely on references to image A. If any of the intermediate steps fail, the entire workflow fail.