-
Notifications
You must be signed in to change notification settings - Fork 741
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
Version v4.27.1 removed from GitHub Repo #1236
Comments
I'm sorry, I messed up and accidentally merged a binary into the source tree! I removed the tags for v4.27.0 and v4.27.1 as those were the affected releases. I'm seeing if I can get the registry to take down those versions as well. Can you use v4.28.0 in the meantime? The content is the same as v4.27.1. |
Lol was waiting for someone to post this. Was sitting around waiting for the github action to finish the 4.28.0 release. Runs are succeeding now assuming that OP just has something like > 4.0 set in his provider file. |
We were relying on features released in v4.27.0 hence the specific provider config posted above. |
Can confirm working with the provider config of:
|
It can be fixed by an update to latest version but I don't know why 4.27.1 is removed so fast... |
Can 4.27.1 be restored? This is breaking existing pipelines for us. |
Seconding @jblazek , this broke a load of nix pipelines for me |
Explanation of the binary incidentTL;DR: I messed up and merged a binary into the project's source tree that increased the size of the repo dramatically (20.01MiB to 32.00MiB). In order to fix this and ensure that future repository clones don't include this bloated size, I force-pushed the repository to the commit immediately before the binary was introduced and removed the tags for the versions with the binary included. I then replayed the two useful commits afterward and released a new version. Sorry for the inconvenience! What happenedThis PR introduced a helpful change in the GitHub repository data source to allow pulling only protected branches. However, it mistakenly included a binary named Afterward, I panicked and reverted the commit in this PR, without thinking clearly: of course a revert commit would still keep the binary in the tree and affect the overall clone size. Shortly after, I also merged this PR to revert a previous PR which broke existing behavior and also created a release for that. Now the state of the provider's source tree was awkward: a PR had been merged containing an unnecessary binary that bloated the repo clone size, and there was a PR on top of it that reverted a bug that needed to be kept. Furthermore, two releases had been created with the binary included. Size comparisonsCloning the repo with the binary included required 32 MiB:
Without the binary added, the cloning process requires just 20.01 MiB:
. How can a binary that according to the original PR takes 24.5 MB of space make up a difference of 12 MiB in the repo? According to this git.kernel.org post, the compression algorithm git uses is zlib, which can be accessed (among other ways) using the CLI zlib-flate. Running
which explains the 12 MB difference we're seeing. ResolutionI decided to remove the binary from the source tree. To do this, I initally used After discussing with a more knowledgeable colleague, I instead decided to force-push the repository to this commit, the last one before the binary was introduced. Afterwards, I replayed the changes that were added in PR 1162 here, and re-reverted I then removed the tags v4.27.0 and v4.27.1 ( Afterwards, cloning the repository is back to its normal size:
Unfortunately, as a consequence of deleting the tags 4.27.0 and 4.27.1, the Hashicorp registry versions of those plugins fail to download and cannot be used. I did not realize this would happen and I apologize for the hassles caused by it. Those affected should use v4.28.0, which is the same code as 4.27.1 minus the spurious binary. I've reached out to Hashicorp about removing those releases from the registry and have not heard back yet. What actions are required of open PRs/Forks?Open PRs may simply merge the main branch in order to avoid any changes in their diffs. Forks should be updated to pull from the latest main branch. What would I do differently next time?So much! I've learned a lot during this episode, and not just about
ConclusionI'm sorry for all the hassle! It won't happen again. |
Thanks for the comprehensive write-up @kfcampbell - things happen and it's OK - I appreciate you taking the time to explain what happened. |
Thankyou for the write-up @kfcampbell it's OK - I appreciate that you took the time to explain this - the version 4.28.0 worked for me. |
Terraform Version
Terraform v1.1.7
on darwin_arm64
Your version of Terraform is out of date! The latest version
is 1.2.5. You can update by downloading from https://www.terraform.io/downloads.htm
Affected Resource(s)
All GitHub Resources
Output
Expected Behavior
Init completes successfully.
Actual Behavior
Init fails with above output.
Steps to Reproduce
terraform init -upgrade with below provider config:
v4.27.1 looks to be removed from the github repo tags whilst still being listed on the provider:
https://registry.terraform.io/providers/integrations/github/4.27.1
The text was updated successfully, but these errors were encountered: