-
Notifications
You must be signed in to change notification settings - Fork 129
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
Fix JReleaser not working anymore #1724
Comments
Might be related to a push I made yesterday evening when computing the target commit to be tagged. The change was reverted a few hours ago. Latest early-access release should have the fix. |
@jponge which version of JReleaser was used when the problem occurred? |
@aalmiray this is with |
What I can tell is that the default tag format is set to
|
OK, then please disregard the comment about JReleaser |
Thanks I will try that!
|
That being said, tags are passed using environment variables: |
Ah, that makes sense as well. Had no idea those values were set using env vars. |
Hi @aalmiray, I think I need your help because I don't understand what's going wrong with the current JReleaser configuration 😉 I've moved most of the workflow to be run locally instead of on GitHub Action (there are only 2 workflows when a tag is created: pushing to Maven Central, and rebuilding the website). To do that I have a
The idea is to have a local branch ready, review it, then perform the release from it once it's all good, and eventually merge it. My main issue is that in this configuration JReleaser doesn't create any release. The computed changelog is locally ok, but there is no tag, no release and no changelog being uploaded. For some reason GitHub Discussions announcements seem disabled as well. For what it's worth I have a release branch here: https://github.com/smallrye/smallrye-mutiny/tree/release/2.7.0-RC4 but it won't be merged since no tag has been created from it. The thing that's puzzling me is that I override a bunch of environment variables so that JReleaser knows the release is not on
and the Maven plugin logs:
Many thanks if you have any idea 🙏 |
Also the POM configuration is here: https://github.com/smallrye/smallrye-mutiny/blob/main/pom.xml#L560 |
Do you have a copy of the |
Interestingly the logs have:
but I cannot see a
|
There's a bunch of merge commits which inflate the changelog's size. The log has a warning
I'd suggest skipping all merge commits by enabling UPDATE: I've seen you've already done this with e9b402f |
I did that (not on this run).
Is there anything else that'd look suspicious?
I recall having such too big changelogs when JReleaser was running from
GitHub Action, but it never prevented a tag from being created, and I was
always able to manually edit the release notes afterwards/
…On Wed, Nov 20, 2024 at 8:00 PM Andres Almiray ***@***.***> wrote:
There's a bunch of merge commits which inflate the changelog's size. The
log has a warning
[WARN] Changelog is larger than 10K characters. Trimmed content added as release body. Original content added as release asset `README.md`
I'd suggest skipping all merge commits by enabling skipMergeCommits in
the changelog.
—
Reply to this email directly, view it on GitHub
<#1724 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGK2JS4IFF42UQDZITGJL2BTL27AVCNFSM6AAAAABQQ6HNVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBZGMZTINJRHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Skipping merge commits still make the changelog too big $ wc target/jreleaser/release/CHANGELOG.md
164 898 14453 target/jreleaser/release/CHANGELOG.md However JReleaser will truncate the release notes while uploading them as a separate release asset
|
I ran a local release and diffed the logs from what you posted. I get pretty much the same results except for the repo owner which was set to |
The local release was ran form the I suspect setting the targetCommitish for a release when the remote branch does not yet exist may be causing trouble https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release But you're not getting this error. |
This is why I had pushed the branch to GitHub in the state where the release version was set, so when JReleaser was called the branch did exist both locally and remotely. |
Ah. That confirms it. I have a bug to file and fix. |
In the interim I might experiment with JReleaser to compute a changelog, and |
Alright. I can confirm that JReleaser will fail with a Followed these steps on a local environment:
A release was successfully posted without errors. |
Thanks @aalmiray, but I had actually pushed the branch, see https://github.com/smallrye/smallrye-mutiny/blob/main/justfile#L25 where I suggest to push the branch after some local checks have been done. The actual JReleaser call is done after that. |
Yes, I recall that. Which means the failure you've got must be caused by something else. |
I've been able to create a release using
|
What happened with the changelog being above 10k in size? |
It got clipped but it's still complete (you get a "read more" link) |
With the update to the SmallRye release workflows, JReleaser is not working anymore:
In the interim I have added a task in
justfile
(akajust jreleaser
) that replicates what was previously working in CI.When we do this locally a proper changelog is being computed, but the GitHub release note isn't updated so we need to do that manually. Still, the Maven plugin is configured with
overwrite
toyes
, so this should perform the update according to the JReleaser docs.The major change compared to the previous workflow (see at tag 2.6.2 https://github.com/smallrye/smallrye-mutiny/tree/b6b0934ee5594630347079426d2a1721d08ab3d9) is that JReleaser is not doing the release and tagging anymore as this is now done by the
maven-release-plugin
in theprepare-release.yml
workflow. The JReleaser configuration has been updated to reflect that change properly (<skipTag>true</skipTag>
).One thing we might explore (first week of November) is to replace the
prepare-release.yml
workflow by using JReleaser again to tag and release with it, which would have us adopt half of the classic SmallRye release workflows.The text was updated successfully, but these errors were encountered: