upgrade sops from v3.4.0 to v3.5.0 #1062
Merged
Conversation
This file contains 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
jmhodges
force-pushed
the
upgrade-sops-to-v3.5.0-gnight
branch
3 times, most recently
from
55c3b7d to
fac670e
Compare
The change from v3.4.0 to v3.5.0 is the first version where the Go module had a real version associated with it. This also includes the first of two module import path changes sops went through to on its way to the current v3.9.1 version. This one is from `go.mozilla.org/sops` to `go.mozilla.org/sops/v3`. v3.5.0 dates back 4 years, but an update directly to 3.9.1 was around 500,000 new lines of code being added at once. Partially, because in v3.8.0, the sops maintainers changed the module path again from `go.mozilla.org/sops/v3` to `github.com/getsops/sops/v3`. There's good reason to do that larger update (mostly, it's holding on to very old versions of other dependencies), but we choose to break that upgrade across multiple bumps for reviewer ease. My current plan is to bump us to v3.5.0, then to v3.7.3 (the last version before the second `getsops` import path change), and then to v3.9.1. I could be told we should just do the one big leap to avoid the two different import path changes.
jmhodges
force-pushed
the
upgrade-sops-to-v3.5.0-gnight
branch
from
fac670e to
6a0d957
Compare
say-yawn
reviewed
Dec 9, 2024
say-yawn
reviewed
Dec 12, 2024
Comment on lines
+229
to
+230
| // LoadEncryptedFileWithBugFixes is a wrapper around LoadEncryptedFile which includes | ||
| // check for the issue described in https://github.com/mozilla/sops/pull/435 |
There was a problem hiding this comment.
Note: The config repo uses SOPS 3.9.1, the bug was fixed on 3.3.0. Since our repo uses newer version highly unlikely this will be a breaking change.
jbuck
approved these changes
Dec 12, 2024
say-yawn
approved these changes
Dec 12, 2024
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.
The change from v3.4.0 to v3.5.0 is the first version where the Go
module had a real version associated with it. This also includes the
first of two module import path changes sops went through to on its way
to the current v3.9.1 version. This one is from
go.mozilla.org/sopstogo.mozilla.org/sops/v3.v3.5.0 dates back 4 years, but an update directly to 3.9.1 was around
500,000 new lines of code being added at once. Partially, because in
v3.8.0, the sops maintainers changed the module path again from
go.mozilla.org/sops/v3togithub.com/getsops/sops/v3.There's good reason to do that larger update (mostly, it's holding on to
very old versions of other dependencies), but we choose to break that
upgrade across multiple bumps for reviewer ease.
My current plan is to bump us to v3.5.0, then to v3.7.3 (the last
version before the second
getsopsimport path change), and then tov3.9.1.
I could be told we should just do the one big leap to avoid the two
different import path changes.