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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.31 seems to be mainline and not stable. I don't like the implications of switching away from stable for prod systems.
1.30.2 should have the fix in and is still the version for stable.
https://my.f5.com/manage/s/article/K000161377#:~:text=1.31.0%0A1.0.0%20%2D%201.30.1-,1.31.1%0A1.30.2,-High/8.1%20(CVSS
IMO we should switch the tag to nginxinc/nginx-unprivileged:1.30-alpine, then we get the 1.30.X upgrades automatically. WDYT @awhdesmond @csieber ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proof of 1.30-alpine working
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise there is also stable-alpine but i think automatic major/minor upgrades can come risky and if something fails it's super unclear.
Automatic Patches OTOH should be best practice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would usually prefer we pin by hash and have automation around updating the hash. However it seems we don't have this here yet.
I am fine with both options. If you have time to monitor the rollout closely we can do
1.30.1->1.31.1. Otherwise we can do1.30which has less risk to change behavior.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually, I believe mainline is recommended for production but in our case, where it's more difficult to release to production, I would agree that going back to stable
1.30.2-alpineis a more appropriate option!However, I would prefer to not use floating tags such as
1.30-alpine, even though we get automatic 1.30.X upgrades. Using immutable tags1.30.2-alpineincreases the visibility & auditability of the change. It also easier to rollback if the patch version broke something (albeit unlikely). Ideally, in GitOps, we can bump the patch version and there will be a diff, and ArgoCD and sync the updated manifest and rollout the deployment to the new image for us. If we use floating tags, ArgoCD can't detect the change, and we need to setimagePullPolicy: Alwaysto pull the new image when restarting.If we want to achieve automatic patching via floating tags, I believe the suggesting by @csieber where we pin by hash and have automation using something a tool like dependabot to update the hash would be more ideal.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good finding ! Hm then yes, in that case, jumping to mainline i will not block. We havn't anyways started using istio, so lets start it off with the right versioning base 👍
Ah okay, my argo / gitops knowledge is not very profound (learning as i use currently). Good to know :)