ROX-26026: Support tagged Konflux builds#13422
Closed
Conversation
|
Skipping CI for Draft Pull Request. |
1456d00 to
8fab87f
Compare
Contributor
|
Images are ready for the commit at d328324. To use with deploy scripts, first |
8fab87f to
e37acf8
Compare
4 tasks
I believe it's just unused https://redhat-internal.slack.com/archives/C073B14UE10/p1732281912631549
Versions like 3.0.62.3 are long gone and are not coming back, we don't need to keep the code which strips out the .0 on the second position.
This was the case before I came but I was still first surprised that my `misha-test-1` tag push triggered `release-ci.yaml`. There I couldn't quickly figure if things would indeed be released.
not because 8 wasn't good.
e37acf8 to
6ab2bfb
Compare
There are multiple things: 1. Used `|` multiline string because otherwise GoLand drops indentation on reformatting. 2. Made `retag-` CEL expressions identical with others. 3. Added `release-` for both PR and push events. It's no-op in `master` but it allows having identical CEL expressions in both release and master branches. Less diff -> less chances for mistakes.
It's not used in the Dockerfile so we don't need to pass it.
Externally determined version gets injected in the BUILD_TAG so that builds use that and don't try to do their own `make tag` thingy which won't give them correct results for tagged builds.
This does the simplest part of https://issues.redhat.com/browse/ROX-27230 The reason it's needed here is because of the commit that follows.
`MAIN_TAG_SUFFIX` became redundant the moment we start injecting `BUILD_TAG`. Two others, i.e. `COLLECTOR_TAG_SUFFIX` and `SCANNER_TAG_SUFFIX` will be used only when the image flavor is `development_build` and when it's not a release build. We know Konflux builds are release builds since #13348. We also know that Konflux builds will have `rhacs` image flavor and that one relies on the unified tagging, i.e. only `BUILD_TAG` is needed and `COLLECTOR_TAG_SUFFIX` and `SCANNER_TAG_SUFFIX` aren't. I thought it's good to be a bit aggressive removing environment variables because there's a lot of them already and dragging around unused ones is worse than leaving them for the future when we'll be onboarding non-release `development_build`-s on Konflux as a daily driver. Besides, that future might look very differently (e.g. we may want to have unified Dockerfiles).
building in Konflux, because the former one failed.
Simplified a couple of loops because it has been long since we pushed to multiple repos at once and I'm not sure we'll need it again.
so that later we can more easily disable the ones for RHACS_BRANDING.
bc9e618 to
d328324
Compare
4 tasks
This was referenced Jan 2, 2025
4 tasks
Contributor
Author
|
I think everything that could have been extracted from this PR, was extracted and likely referenced. I'm closing this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
change me!
User-facing documentation
Testing and quality
Automated testing
How I validated my change
change me!