Detect major dependency version bumps #571
No reviewers
Labels
No Label
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/helm-chart#571
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "justusbunsi/helm-chart:409-detect-major-version-bumps"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As seen in #507 and #569, there is no guarantee for us that minor
dependency updates are actually minor updates for the dependent
application itself. The Chart version might be minor - and therefore
automatically merged when build is green - but the used Docker image
inside the Chart could still be a major version change.
To effectively prevent such automerge when the application major version
changes, there is now a test file that has the currently used major
versions hard-coded. In case of an actual major bump, this file has to
be adjusted.
Looking at
redis-cluster
, there might be several major Chart versionswith the same major application version.
This PR is related to #409 but does not fully resolve it.
@ -10,3 +10,3 @@
.PHONY: unittests
unittests:
helm unittest --strict -f 'unittests/**/*.yaml' ./
helm unittest --strict -f 'unittests/**/*.yaml' -f 'unittests/dependency-major-image-check.yaml' ./
I added the major image check at the end of the suite so that it would be the last test file to run. The current
v3.0.6
of helm-unittest suffers from an excessive log output1 which obscures the test results and failures in our builds.https://github.com/helm-unittest/helm-unittest/issues/237 ↩︎
Major-change failures look like this:
WIP: Detect major dependency version bumpsto Detect major dependency version bumpsAwesome, thanks!
Yes, if there are major changes in the chart, there will be a major version bump as well. So it could be for both reasons, major application version update or chart version.
Good to have the security now to prevent issues like #507!
I also thought in more detail how we could go with the bitnami chart updates, i.e. we could ensure staying on the latest chart version but encouraging users to fix their image tag to a version compatible with their actual PG version.
This has two benefits:
But more on this soon...
With this PR merged, are we ready to enable branch automerging for minor & friends?
And do we really want to "skip changelog" for such features? Sure they are chart internal but I stil think they are worth being mentioned in a changelog.
Good point on the labels. Let's remove them on both my PRs from today.
Regarding automerge: From what I see there are still some things to ensure for #409 really be resolved. E.g that our mapping for ports has an effect. In general, all subcharts settings we have in our values should be verified being templated correctly. We had regressions in the past I would like to prevent that for the future. Otherwise we always go through the subchart changes ourself to see what changed.
If users add their own subchart values, that's out of our scope. Those we set are our responsibility to check.