-
Notifications
You must be signed in to change notification settings - Fork 6.4k
feat: enhance build metadata to include resolved revision information (fixes #20768) #24634
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
🔴 Preview Environment stopped on BunnyshellSee: Environment Details | Pipeline Logs Available commands (reply to this comment):
|
090a8d5
to
d5b99ab
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #24634 +/- ##
=========================================
Coverage ? 60.73%
=========================================
Files ? 405
Lines ? 66316
Branches ? 0
=========================================
Hits ? 40276
Misses ? 22774
Partials ? 3266 ☔ View full report in Codecov by Sentry. |
cf0d4ae
to
4197551
Compare
Signed-off-by: Fredrik Larsson <[email protected]>
- Introduced `Test_newEnv_RevisionMetadata_AllResolutionTypes` to validate various resolution types and their corresponding environment variables. - Added `Test_newEnv_RevisionMetadata_EmptyAndNil` to ensure correct behavior when metadata is nil or empty. - Enhanced existing tests to verify the presence and correctness of environment variables based on revision metadata. Signed-off-by: Fredrik Larsson <[email protected]>
- Introduced `buildMetadataHasChanged` method to determine if build metadata environment variables have changed between revisions, ensuring refreshes are only triggered when necessary. - Added `appParametersWouldChange` method to check for differences in application source parameters during environment substitution. - Updated the revision update logic to incorporate checks for build metadata changes alongside file changes, improving the efficiency of the refresh process. Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
Signed-off-by: Fredrik Larsson <[email protected]>
ae853d6
to
40bf961
Compare
Signed-off-by: Fredrik Larsson <[email protected]>
One test (different every time) in one pipelines, either unit test with -race or one of the e2e pipelines, seems to fail randomly. I dont know if this is common or if it is related to this. If someone familiar with the pipelines can tell me if the tests are somewhat flaky or I need to debug more would be appreciated |
This adds build environment metadata for how the targetRevision was resolved, e.g. was it a range, and if so what was the original targetRevision, what was the resolved tag.
This is useful for targeting a tag range, e.g.
v*
, and passing the resolved tag into the chart as a parameter to override image tags.Also makes change detection take build metadata into account, if it is referenced, when deciding on whether to sync or not. This is necessary to cause a sync if the underlying revision(e.g. git commit SHA from a tag range
v*
) is the same while the intermediate resolved revision does change, e.g. a new tag(v1.0.1) is pushed to point to the same commit as the previous(v1.0.0).Closes #20768
Checklist: