Introduce release process through GHA

[kaikreuzer]

No description provided.

[Copilot]

Pull Request Overview

This PR introduces a comprehensive GitHub Actions workflow for automated Maven Central releases of the static-code-analysis project. The workflow handles the complete release lifecycle including version updates, deployment, and preparation for the next development iteration.

Key changes:

• Automated release process with manual version input parameters
• Integration with Maven Central via OSSRH and Central Publisher Portal
• Post-release verification to confirm Maven Central availability

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The actions/create-release@v1 action is deprecated. Use softprops/action-gh-release@v1 or the newer gh CLI commands instead for better security and maintenance.

[kaikreuzer]

@copilot open a new pull request to apply changes based on this feedback

[wborn]

Looks like a nice way for being able to do SAT releases using GHA! The only improvement I saw is what Copilot also found, i.e. more generically handling POM files. But maybe there are some pom.xml files also used in tests making it less straight forward?

Did you also consider using the maven-release-plugin? It also checks if there are any snapshot dependencies before doing a release. We can always still use that in a follow up PR of course. 😉

[Copilot]

@kaikreuzer I've opened a new pull request, #526, to work on those changes. Once the pull request is ready, I'll request review from you.

[Copilot]

@kaikreuzer I've opened a new pull request, #527, to work on those changes. Once the pull request is ready, I'll request review from you.

[kaikreuzer]

Did you also consider using the maven-release-plugin?

No, I didn't.

We can always still use that in a follow up PR of course. 😉

Yeah, feel free!

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 12 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[holgerfriedrich]

@kaikreuzer do you want to start the publishing without further measures (no dry-run or approval of the created binary?) I know this is not that easy as the version plugin changes the git.

You could also consider using actions/upload to upload the build artifact to GH - in case sonatype upload fails, it could be useful to have it at hand.

[Copilot]

@kaikreuzer I've opened a new pull request, #528, to work on those changes. Once the pull request is ready, I'll request review from you.

[kaikreuzer]

do you want to start the publishing without further measures (no dry-run or approval of the created binary?)

@holgerfriedrich What would be your suggestion? I'm open to any good approach.

[holgerfriedrich]

@kaikreuzer I asked the AI to create what I described. With some more infos, the output seems reasonable:

holgerfriedrich@43400f1

It introduces the parameter, uses it as a condition for all publish and git push sections.

Additionally, it should upload the artifacts to GH. This may need a different pattern for the respective file names.

Overall, this is the built-in and easy solution.
Benefit is that we can test the artifact.
Downside is that we need to retrigger later, setting all the parameters (version, next version) again and correctly.
I order to get around this, we would need to use those additional actions built specifically to allow a user interaction during between steps of a build.

[holgerfriedrich]

@kaikreuzer could you pls. rebase? If I run the action, it fails during build because of changed xsd. This was fixed on main in the meantime.

[kaikreuzer]

@holgerfriedrich I just rebased it.

[holgerfriedrich]

@kaikreuzer almost got the first part running, see https://github.com/holgerfriedrich/static-code-analysis/commits/pr-dryrun
Upload still does not pick artefacts.

[holgerfriedrich]

How shall we proceed? If I look at https://github.com/holgerfriedrich/static-code-analysis/actions/runs/19986744870, I see that collecting artefacts worked, but the content of the zip seems not of much use to me.
Do you want to proceed with this idea or should we just get it working without the dryrun feature?

[kaikreuzer]

but the content of the zip seems not of much use to me

Not much use or not much sense? If I look at the content, it at least seems that it correctly built the jars, right?

[holgerfriedrich]

Yes, it did. But not sure if this is useful.

You could give it a try without this changes.
I think we merged everything we want for 0.18.

[kaikreuzer]

That wasn't too successful for a start...
https://github.com/openhab/static-code-analysis/actions/runs/20194428448/job/57976326040

[holgerfriedrich]

Did you check the GPG key stored in secrets?
It should be armored, i.e. start with -----BEGIN PGP PRIVATE KEY BLOCK-----

[kaikreuzer]

Thanks @holgerfriedrich, it seems I indeed had a wrong format of the key.
Now publishing works, the pipeline now only fails because it tries to do a commit to main: https://github.com/openhab/static-code-analysis/actions/runs/20249411534/job/58137742534

I'd like to grant the github action an exception on the branch protection rule, but I couldn't yet figure out, how to do that...

[holgerfriedrich]

@kaikreuzer I don't know how the branch protection is set up for this repo. If you could switch from classic to ruleset based protection, there is a bypass option already given:

[holgerfriedrich]

@kaikreuzer Surely there was no time during the last days. I would appreciate if you could proceed with that in the next weeks.

[kaikreuzer]

Sure @holgerfriedrich, I'll continue on this. I actually did already last week and temporarily removed the branch protection, but then stumbled over the next issue that I wasn't sure how to resolve, see https://github.com/openhab/static-code-analysis/actions/runs/20298054017/job/58296420614.

[holgerfriedrich]

@kaikreuzer Maybe it is the pom from the test folder again.... remember we had to add an exception in another place of the script:

 for pom in $(find . -name pom.xml -not -path "*/target/*" -not -path "*/src/test/resources/*"); do

To get a better picture what could be wrong, maybe echo the name of the pom in this loop:

   # Update parent version in all child POMs
  # Find all pom.xml files except the root pom.xml
  for pom in $(find . -name pom.xml ! -path "./pom.xml"); do
    if [ -f "$pom" ]; then
      mvn versions:update-parent -DparentVersion=0.19.0-SNAPSHOT -f "$pom"
      mvn versions:commit -f "$pom"
    fi
  done