-
Notifications
You must be signed in to change notification settings - Fork 10
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
ci: test the publish workflow in PRs if changed #408
Conversation
0f8b0ea
to
8630d25
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this PR is actually beneficial.
We already publish to maven local for the plugin tests so a misconfiguration of the tasks would become apparent there.
On top of that, due to the added if statements, it makes it harder for a human to parse, what the workflow does 99% of the time.
This CI workflow would not be running at all before a release. And correctly defining a GitHub Actions workflow is often not easy and requires many iteration with GitHub actually executing the workflow to detect issues. We would only see the misconfigurations of the workflow by triggering many releases, thereby polluting the public changelog and forcing users into more updates. With the experience I have so far with the complexity of reconfiguring such workflows I'd say it's worth running this here, even if it is not a 100% reproduction of the actual release workflow. |
8630d25
to
d775f44
Compare
Any other opinions on whether this is worth it? |
Not a strong opinion, but I favor of the change. |
d775f44
to
5a837ea
Compare
5a837ea
to
af57e33
Compare
🎉 This PR is included in version 4.6.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This PR runs the GitHub Actions publish workflow in case we have changed it in a PR. Without this, testing changes to this workflow is guess work until a release appeared. The workflow has been modified to only publish to maven local in PR runs to avoid spamming repositories with artificial testing releases. That way, we don't test everything about publishing, but a complete misconfiguration of the publishing tasks or pipeline should become visible. Docker publishing is not tested and skipped here as I couldn't find an easy way to not push things to our repos.