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
Incorrect (duplicate) prerelease version determined even when git notes exist #1708
Comments
Is it possible that some of the changes you made between versions rewrote history. It is important for the commit of the previous release to be found in the history of the branch. I haven't dug into the details of your proposed change, but I use pre-releases regularly without seeing the issues you are describing. I've also manually added notes following the documented steps in a few cases where semantic-release was added to an existing project and had success in those cases as well. Is it possible that something is simply not in the state that is expected in your scenario? |
@travi Thanks for the response! In the case of rewriting history, all permutations of Moreover, And looking at the Also, running So all the notes exist, they have the proper contents, they point to commits that exist, those commits are properly tagged, those tags are all visible from the tip of My proposed change is the addition of line 309 in Anything's possible, so I'll whip up a MRE and see if I can replicate the behavior :) |
Update: So I attempted to create a MRE here on my local machine, but I couldn't initially reproduce the issue. Even when deploying directly from my development environment, it still worked. Issuing the raw command that failed in the other repo succeeded in the MRE repo: $ git notes --ref semantic-release show v2.0.0-canary.1 | cat
{"channels":["canary"]} Huh. In the old repo, I kept getting errors like: git notes --ref=semantic-release show v3.0.0-canary.1
error: no note found for object 4dbe4cb6c81c408cf34869aa295c52d91eb37940 Which was very strange to me because Unlike my local environment where I set up the MRE, I have my GitHub Actions pipeline setup so that all tags must be signed via To evidence the two repos using different tags types, I ran Original repo (workflow-playground): Tag Attempted MRE: All tags in this repo are lightweight (they point directly to commits). And for the cherry on top: forcing If I'm understanding this right, as a consequence of this bug, it appears all notes are functionally ignored by I also saw #1192 which makes me think Arguments for supporting annotated tags too, from git-scm and stackoverflow:
|
i'll look deeper into your details later, but would like to at least point out that annotated tag support was reverted, as mentioned in #1262. thanks a lot for investigating so thoroughly. |
As a final addition to the above, I implemented the
So now my Thanks for this awesome package! |
Just want to second the appreciation for your thorough investigation here Bernard 👍🏼 |
same is happening with me too |
I have a fork that rebases my PR fix onto semantic-release master every now and then. Once I get around to addressing gr2m's concerns (it keeps falling off my todo list sadly), I believe the maintainers might give my PR a second look and I can do away with the fork. |
Is rebasing prerelease branches essentially not supported? I've now dug into how the notes stuff worked to be able to salvage prerelease branches that have been rebased and end up in this broken state... (I missed the troubleshooting entry) but I'd love to be able to rebase the branches without having to worry about this. @Xunnamius does your change address this? I guess I'm a little fuzzy on exactly what it's fixing — I guess it ensures that the notes point to commits orphaned from rebasing so that they still show up when calculating the next prerelease version? |
I've got this issue on some of my repos. How to get it not work :Branch architecture :
Step to reproduce :Push something from a dev branch into That will create a release ~> git fetch origin +refs/notes/semantic-release:refs/notes/semantic-release
~> git notes --ref semantic-release show v1.0.0-beta.1
{"channels":["beta"]} Merge That will create a release ~> git fetch origin +refs/notes/semantic-release:refs/notes/semantic-release
~> git notes --ref semantic-release show v1.0.0-rc.1
{"channels":["rc"]} Push something new on That will try to make a ~> git fetch origin +refs/notes/semantic-release:refs/notes/semantic-release
~> git notes --ref semantic-release show v1.0.0-beta.1
{"channels":["rc"]} I think the tag note must be : {"channels":["rc", "beta"]} But even in editing the note like this didn't unlock the CI and ~> # that didn't work
~> git fetch origin +refs/notes/semantic-release:refs/notes/semantic-release
~> git notes --ref semantic-release show v1.0.0-beta.1
{"channels":["rc", "beta"]}
~> git notes --ref semantic-release add -f -m '{"channels":["rc", "beta"]}' v1.0.0-beta.1
~> git push origin refs/notes/semantic-release If someone got a workaround to unlock CI when we got this case, it can help me a lot. Also, I've some trouble to understand why Can someone explain to me ? |
As a workaround, I create a script that replace It probably need some more work. |
@jrolfs If you're experiencing the same problem I was, then at its root is that all notes are functionally ignored by semantic-release for repositories using annotated tags as explained in my very first posts above. My first PR makes semantic-release pay attention to annotated tags by using the commit hash instead of the tag ref when semantic-release executes the
My second PR stops semantic-release from asking for an additional message when creating an annotated tag to mark the new release, which screwed up my CD pipelines. I merge my pre-release branches using @shiipou This issue will happen on repos that are using annotated tags (e.g. if you use gpg to sign your commits/tags). This is because, at least at the time I opened this issue, notes are ignored by semantic-release for repositories using annotated tags. semantic-release uses notes to enable complex configurations like when releases on multiple channels are associated with a single commit. |
@Xunnamius ah, no this was a red herring/I was totally mistaken. My issue is with Git tags as of course rebasing clobbers the previous tags. I guess I had just gotten used to being able to rebase prerelease branches with Changesets since it uses files instead of tags. Pls to ignore — 😬 — sorry y'all |
Hello, any update ? |
I'm using GitHub Flow/Trunk Based Development thanks to
semantic-release
, and it's great! I'm going to move all my packages over to asemantic-release
CI/CD trunk-based flow, but most of them already have manually published releases. So, to create a uniform repo configuration for my packages, I've been playing with a dummy GitHub Actions/semantic-release repo. I tagged and manually released some initial commits tomain
to simulate switching a project with preexisting tags and releases over tosemantic-release
. I made several more commits tomain
and several successful semantic releases. Next, I configured a prerelease branchcanary
(channel is alsocanary
) offmain
and pushed a breaking change.semantic-release
published the prerelease no problem:v3.0.0-canary.1
.Current behavior
However, I made some more changes, I pushed them, I expected release
v3.0.0-canary.2
, but instead I got an error:So... it's trying to re-publish the same prerelease version,
v3.0.0-canary.1
? A quick scan of the issues shows problems similar to mine, perhaps related. The troubleshooting docs also talk about force pushing and git notes.Some facts about my issue:
v3.0.0-canary.1
is in the git history ofcanary
:{"channels":[null]}
while 6cae4d5 is the note with{"channels":['canary']}
:semantic-release
doesn't "see" thev3.0.0-canary.1
release it just made, instead finding the oldv2.3.4
release:And the 2d branch graph:
This same problem happens with GitHub Actions runners as well as my local machine when running
npx semantic-release -d
. I ended up spelunking down into the code similar to #1685 to see what was going on. It turns out that the problem may be git itself, or (perhaps more likely) the assumptions about howgit notes show
handles references. Specifically this line. It seems commands likegit notes --ref semantic-release show v2.1.0
do not work (or at least don't seem to). However, when using the commit hash instead of the tag name, i.e.git notes --ref semantic-release show 1eeba8e
, everything works:After forking
semantic-release
, adding a line that replaces the tag ref with the hash of the commit its pointing to, and replacingsemantic-release
withXunnamius/semantic-release
in my package.json, pushes to my prerelease branch are now released properly.Expected behavior
v3.0.0-canary.1
is found as the previous release tag with branchcanary
and channelcanary
. The next release should then bev3.0.0-canary.2
.Environment
@semantic-release/commit-analyzer
@semantic-release/release-notes-generator
@semantic-release/exec
@semantic-release/changelog
@semantic-release/npm
@semantic-release/git
@semantic-release/github
The text was updated successfully, but these errors were encountered: