Add automated release job for Smart Test Picker

[ljubisap]

Goal

Create a repeatable release job for Smart Test Picker that prepares, builds, signs and publishes a project release using the existing Maven Central setup.

The initial goal is to establish a reliable release process before deciding which additional release automation should be added later.

Motivation

The Maven Central / Sonatype setup for Smart Test Picker is already largely prepared, but the project still needs a standardized release workflow.

Releases should not depend on manually running multiple Maven commands from a developer machine or manually modifying project versions.

The release process should be reproducible and executable from CI.

Scope

Create a release job/pipeline that can be manually triggered and performs the required release steps.

The exact CI implementation can follow the infrastructure used by the project, but the release logic should not depend unnecessarily on a specific developer machine.

Proposed release flow

The initial release process should roughly follow:

manual release trigger
        ->
validate repository state
        ->
validate requested release version
        ->
build and run tests
        ->
prepare release version
        ->
create release artifacts
        ->
sign artifacts
        ->
publish to Maven Central
        ->
create Git tag
        ->
prepare next development version

The exact ordering should be verified against the Maven Central publishing mechanism and the versioning strategy used by the project.

Release parameters

The job should at minimum allow specifying:

releaseVersion
developmentVersion

Example:

releaseVersion=0.1.0
developmentVersion=0.2.0-SNAPSHOT

Where possible, the development version should eventually be derivable automatically from the release version, but this is not required for the first implementation.

Preconditions

Before publishing, the job should verify that:

• the expected branch is being released
• the working repository state is clean
• the release version is not a SNAPSHOT version
• the development version is a SNAPSHOT version
• the Git tag for the release does not already exist
• all required credentials are available
• artifact signing is configured
• the complete build succeeds
• all required tests succeed

The job must fail before publishing if any release prerequisite is not satisfied.

Maven Central publishing

The job should use the existing Smart Test Picker Maven Central configuration and credentials.

Credentials must be provided through CI secrets and must not be stored in the repository.

This includes, where applicable:

• Maven Central / Sonatype credentials
• GPG private key
• GPG passphrase
• Git credentials required for tagging or pushing version changes

Signing

Published artifacts must be signed as required by Maven Central.

The private signing key must only exist temporarily inside the release environment and must not be committed to the repository or persisted in build artifacts.

Git changes

The release workflow should define and document how Git history is modified.

A typical flow could be:

0.1.0-SNAPSHOT
      ->
0.1.0
      ->
tag v0.1.0
      ->
0.2.0-SNAPSHOT

The implementation should make it clear whether this is performed through Maven Release Plugin or through explicit version-management commands.

This decision should be documented as part of this issue.

Failure handling

Special attention should be given to partial releases.

The job should define what happens if a failure occurs after:

• the version has been changed
• a commit has been created
• a Git tag has been created
• artifacts have been uploaded
• Maven Central publishing has been initiated

Where possible, irreversible actions should happen as late as possible.

A failed release should leave enough information to determine what was published and what needs to be cleaned up or resumed.

Logging

Release logs should clearly show the major release stages without exposing credentials or signing secrets.

Example:

Release Smart Test Picker 0.1.0

[OK] Repository validation
[OK] Version validation
[OK] Build
[OK] Tests
[OK] Artifact generation
[OK] Artifact signing
[OK] Maven Central upload
[OK] Git tag v0.1.0
[OK] Development version 0.2.0-SNAPSHOT

Documentation

Add release documentation describing:

1. How to trigger a release.
2. Required parameters.
3. Required CI credentials.
4. Expected Git changes.
5. Maven Central publishing behavior.
6. How to verify that a release was successfully published.
7. What to do when a release fails.
8. How to perform or test a release without publishing a production version.

Dry-run / validation mode

If practical, provide a way to execute the release workflow without publishing artifacts.

A dry run should validate as much of the process as possible, including:

• version handling
• build
• tests
• artifact creation
• signing configuration

without creating a real Maven Central release or permanent Git tag.

Out of scope

The first version of the release job does not need to include:

• automatic releases on every merge
• automatic semantic version calculation
• automatic changelog generation
• GitHub Release creation
• release notes generation
• automatic announcement of new releases
• release candidate channels
• nightly releases

These can be considered separately once the basic release pipeline is stable.

Acceptance criteria

• Smart Test Picker has a CI release job/pipeline.
• A release can be triggered manually.
• Release and next development versions can be provided.
• The complete project is built and tested before publishing.
• Release artifacts are generated correctly.
• Maven Central artifacts are signed.
• Secrets are supplied exclusively through CI credentials.
• Artifacts can be published to Maven Central.
• A Git tag is created for a successful release.
• The project is moved to the next development version after the release.
• Existing tags/releases cannot accidentally be overwritten.
• Failure behavior is documented.
• The release procedure is documented in the repository.

Follow-up

Once the first release job works reliably, evaluate separate follow-up issues for:

• automated GitHub Release creation
• release notes / changelog generation
• automatic version calculation
• release candidate support
• publishing example/demo projects against released Smart Test Picker artifacts
• running the end-to-end demo against the released Maven Central version instead of locally built artifacts