[release] Wrong commit may be used when pushing tag
Background
As described in https://github.com/jreleaser/jreleaser/discussions/1676
Task List
- [x] Steps to reproduce provided
- [x] Stacktrace (if present) provided
- [x] Example that reproduces the problem (link to git repository is ideal)
- [x] Full description of the issue provided (see below)
Steps to Reproduce
- check out an earlier branch or commit (
detached HEAD) - make a new commit on origin, and fetch it locally
- execute a full release that pushes a tag, note that the log mentions the commit from (1)
- when the release is published, note that the tag references the newer commit instead of the one checked out
Expected Behaviour
JReleaser should use the current HEAD
Actual Behaviour
JReleaser does not use the current HEAD, and instead uses the latest commit
Environment Information
- Operating System: macOS 14.4.1 (Sonoma)
- JReleaser Version: 1.12.0
- JDK Version: openjdk 17.0.10
Please paste stacktraces from [out|build|target]/jreleaser/trace.log.
https://gist.github.com/haydenbaker/a826323865f4299e57d51da4d49d6ed7
Is this going to be fixed? This breaks reproducible builds among other things
As far as I can tell this only occurs while a commit is performed on the same branch during a release. A fix will be posted in a future release. We had to take it out of the latest release because there was not enough time to properly work on it.
My flow is like that:
-
mvn release:prepare(adds aprepare release Xcommit) -
mvn release:performto a local staging directory (adds aprepare next development versioncommit) -
git checkout X - run jreleaser with local staging directory
According to the logs the JReleaser sees a prepare release X as a HEAD but still creates a tag pointing to prepare next development version commit
@wendigo I see. Your case is different though the observable result is the same.
What I understand from your flow is that the tag is created during the prepare release block. Then JReleaser sees the next HEAD after the version change which no longer points to the same commit as the tag created in the previous step.
Somehow JReleaser would have to be instructed to grab the commit that matches an existing tag, which it can't do at the moment. However, what you may do in the meantime is tell JReleaser to not create a tag by setting skipTag to true in the release section of the DSL.
@wendigo could you post a link to a gist with your trace.log?
Also, I'll update the logs to include the tagged sha. For now it looks like this
[DEBUG] tagging local repository with 1.50.0
@aalmiray logs are here: https://github.com/airlift/airbase/actions/runs/11032182209
And here's a gist with the trace.log taken from the link above: https://gist.github.com/wendigo/c75c10cfb4533f6840179dd0b5c5cb65
@aalmiray is this enough?
Yes, this should be enough
Seems like we may have hit this issue again, but for the release to Maven. Is it possible for this same issue to occur there as well? Our jars released to Maven were missing a small change we made, and the releaser had checked that specific commit out before running JReleaser.
Staged artifacts are independent from the release as they are placed in a staged directory by the build. Can you describe what happened?
@wendigo from the log you linked I can see the following:
> Display git status and history, checkout release tag"
Run git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
e235466 [maven-release-plugin] prepare for next development iteration
fdf4bc7 [maven-release-plugin] prepare release 179
Note: switching to '179'.
...
HEAD is at fdf4bc7. Then JReleaser is invoked. The log shows
[INFO] JReleaser 1.14.0
[INFO] Configuring with jreleaser.yml
[INFO] - basedir set to /home/runner/work/airbase/airbase
[INFO] - outputdir set to /home/runner/work/airbase/airbase/out/jreleaser
[INFO] Reading configuration
[INFO] git-root-search set to false
[WARN] Auto configure detected '' as default branch but project has 'master' configured
[INFO] Loading variables from /home/runner/.jreleaser/config.properties
[WARN] Variables source /home/runner/.jreleaser/config.properties does not exist
[INFO] Validating configuration
[INFO] Strict mode set to false
[INFO] Project version set to 179
[INFO] Release is not snapshot
[INFO] Timestamp is 2024-09-25T11:35:42.781881259Z
[INFO] HEAD is at fdf4bc7
[INFO] Platform is linux-x86_64
[INFO] dry-run set to false
Yes, but the tag points to e235466, not to fdf4bc7
It's still not working - I've tried early access and now the tag is created one commit before the checked out commit.
The checked out commit is 206692e080c130488410fe2138e81c83f20cd9da The created tag points to 873d018c65b49588977bbea5bb17fce499ddc8b8
https://github.com/airlift/airbase/actions/runs/11481029901 https://github.com/airlift/airbase/releases/tag/191
trace.log reveals
[INFO] Project version set to 191
[INFO] Release is not snapshot
[INFO] Timestamp is 2024-10-23T13:34:10.165507195Z
[INFO] HEAD is at 206692e
I believe the problem may be on this line
https://github.com/jreleaser/jreleaser/blob/3efdf067d36998d96ba26f85a78092e52f015b8d/sdks/jreleaser-github-java-sdk/src/main/java/org/jreleaser/sdk/github/GithubReleaser.java#L351
Where the target is set to a branch name whose HEAD may point to a different commit.
@aalmiray seems consistent with the observable outcome
Latest early-access has another fix. Please give it a try whenever you can.
I'll try it soon and let you know :)
Now the jreleaser fails with:
org.jreleaser.model.JReleaserException: Unexpected error when creating release
at jreleaser.shadow.org.jreleaser.workflow.ReleaseWorkflowItem.doInvoke(ReleaseWorkflowItem.java:41)
at jreleaser.shadow.org.jreleaser.workflow.AbstractWorkflowItem.lambda/tmp/jreleaser9314267191262766005.sh(AbstractWorkflowItem.java:43)
at jreleaser.shadow.org.jreleaser.engine.hooks.HookExecutor.execute(HookExecutor.java:70)
at jreleaser.shadow.org.jreleaser.workflow.AbstractWorkflowItem.invoke(AbstractWorkflowItem.java:43)
at jreleaser.shadow.org.jreleaser.workflow.WorkflowImpl.doExecute(WorkflowImpl.java:129)
at jreleaser.shadow.org.jreleaser.workflow.WorkflowImpl.execute(WorkflowImpl.java:54)
at jreleaser.shadow.org.jreleaser.cli.FullRelease.doExecute(FullRelease.java:220)
at jreleaser.shadow.org.jreleaser.cli.AbstractModelCommand.execute(AbstractModelCommand.java:90)
at jreleaser.shadow.org.jreleaser.cli.AbstractCommand.call(AbstractCommand.java:52)
at jreleaser.shadow.org.jreleaser.cli.AbstractCommand.call(AbstractCommand.java:37)
at jreleaser.shadow.picocli.CommandLine.executeUserObject(CommandLine.java:2045)
at jreleaser.shadow.picocli.CommandLine.access500(CommandLine.java:148)
at jreleaser.shadow.picocli.CommandLine.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2465)
at jreleaser.shadow.picocli.CommandLine.handle(CommandLine.java:2457)
at jreleaser.shadow.picocli.CommandLine.handle(CommandLine.java:2419)
at jreleaser.shadow.picocli.CommandLine.execute(CommandLine.java:2277)
at jreleaser.shadow.picocli.CommandLine.execute(CommandLine.java:2421)
at jreleaser.shadow.picocli.CommandLine.execute(CommandLine.java:2174)
at jreleaser.shadow.org.jreleaser.cli.Main.execute(Main.java:98)
at jreleaser.shadow.org.jreleaser.cli.Main.run(Main.java:94)
at org.jreleaser.tool.JReleaser.main(JReleaser.java:47)
Caused by: jreleaser.shadow.org.jreleaser.model.spi.release.ReleaseException: jreleaser.shadow.org.jreleaser.sdk.commons.RestAPIException: 422: Unprocessable Entity
at jreleaser.shadow.org.jreleaser.sdk.github.GithubReleaser.createRelease(GithubReleaser.java:236)
at jreleaser.shadow.org.jreleaser.sdk.git.release.AbstractReleaser.release(AbstractReleaser.java:59)
at jreleaser.shadow.org.jreleaser.engine.release.Releasers.release(Releasers.java:56)
at jreleaser.shadow.org.jreleaser.workflow.ReleaseWorkflowItem.doInvoke(ReleaseWorkflowItem.java:39)
... 20 more
Caused by: jreleaser.shadow.org.jreleaser.sdk.commons.RestAPIException: 422: Unprocessable Entity
at jreleaser.shadow.org.jreleaser.sdk.commons.ClientUtils.lambda(ClientUtils.java:120)
at jreleaser.shadow.feign.InvocationContext.decodeError(InvocationContext.java:126)
at jreleaser.shadow.feign.InvocationContext.proceed(InvocationContext.java:72)
at jreleaser.shadow.feign.RedirectionInterceptor.intercept(RedirectionInterceptor.java:44)
at jreleaser.shadow.feign.ResponseInterceptor.lambda(ResponseInterceptor.java:69)
at jreleaser.shadow.feign.ResponseHandler.handleResponse(ResponseHandler.java:63)
at jreleaser.shadow.feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:98)
at jreleaser.shadow.feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:48)
at jreleaser.shadow.feign.ReflectiveFeign.invoke(ReflectiveFeign.java:99)
at jdk.proxy2/jdk.proxy2..createRelease(Unknown Source)
at jreleaser.shadow.org.jreleaser.sdk.github.Github.createRelease(Github.java:340)
at jreleaser.shadow.org.jreleaser.sdk.github.GithubReleaser.createRelease(GithubReleaser.java:361)
at jreleaser.shadow.org.jreleaser.sdk.github.GithubReleaser.createRelease(GithubReleaser.java:232)
... 23 more
Will rollback shortly and try a different approach
🎉 This issue has been resolved in v1.15.0 (Release Notes)
@aalmiray actually it's not resolved: https://github.com/airlift/airbase/actions/runs/11642688839/job/32422574081
Code is checked out at HEAD is at 33636f0 but github tag points to HEAD~1