kie-issues#2404: 10.3.x+ stream: Re-write drools release jobs to be local scripts invoked in Apache Jenkins and remove old ones.

[Kusuma04-dev]

closes #7140,

This PR introduces local-first release automation scripts for the consolidated incubator-kie repository and updates the Jenkins release pipelines to use them.

What the Release Scripts Do:

script/release/01-update-version.sh — Updates the Maven version across all reactor modules (Drools, OptaPlanner, Kogito Runtimes, Kogito Apps).

script/release/02-rc-commit.sh — Creates a short-lived local release branch, bumps to the exact release version, creates the R commit, tags the RC (e.g. 10.3.0-rc1), and deletes the temporary branch. Only the tag is pushed.

script/release/03-build.sh — Runs mvn clean install -Dfull across the full reactor and installs JARs to ~/.m2/repository.

script/release/04-deploy-to-staging.sh — Signs artifacts with GPG and deploys them to the Apache Nexus staging repository. Dry-run by default; requires --deploy to actually upload.

script/release/05-tag-release.sh — Promotes an approved RC tag (e.g. 10.3.0-rc1) to the final release tag (10.3.0) once the vote passes.

script/release/release-all.sh — Master orchestrator that runs steps 02 → 03 → 04 in sequence. Accepts --version, --tag, --skip-tests, --deploy, --push-tag, --maven-opts, and --dry-run.

Jenkins Pipeline Updates:

.ci/jenkins/project/Jenkinsfile.103xplus.release — New pipeline that delegates the full RC workflow to script/release/release-all.sh.

.ci/jenkins/Jenkinsfile.103xplus.deploy & .ci/jenkins/Jenkinsfile.103xplus.promote — New pipelines streamlined to avoid duplicating release tagging and signing logic now handled by the scripts.

Backups preserved: Kept .ci/jenkins/project/Jenkinsfile.release, .ci/jenkins/Jenkinsfile.deploy, and .ci/jenkins/Jenkinsfile.promote to ensure zero disruption until the new pipelines are verified in CI.

[jomarko]

I can not do a review without a ticket or acceptance criteria that would explain me:

• am I from the group of users authorized to run such scripts?
• do I need some credentials to run such scripts?
• what is result of the scripts, where should it be uploaded?
• will be the scripts started only by CI robots?
• what is the command I should start?
• are the scripts isolated per repository?
• does scripts something like "full build" of all repositories of specific version/commit?

[Kusuma04-dev]

Thanks @jomarko ,

You don't need to run a full build. Complete build logs and testable artifacts are already available in the kie-release-10.3/evidence repository for verification.

• Authorized users: Anyone can run local builds or dry-runs. Official releases are executed through Jenkins.
• Credentials: No credentials are needed for local RC builds or testing. Publishing credentials (NPM, VSCE, GPG, etc.) are pre-configured in Jenkins and used only for official releases.
• Output and upload location: For a local dry-run, the scripts generate artifacts under release-artifacts (in kie-tools) and the local .m2 repository (in kie). If the release is run through Jenkins, the generated artifacts are uploaded to Apache SVN dev and Nexus Staging for voting, and are published to public registries after approval.
• CI vs local execution: Official releases run on Jenkins, but the release scripts can also be executed locally.

Dry-run commands:

incubator-kie:

./script/release/release-all.sh --version 10.3.0 --tag 10.3.0-rc1 --skip-tests --dry-run

incubator-kie-tools:

./scripts/release/release-all.sh 10.3.0 --rc --skip-build

• Repository isolation: Yes. The release scripts are self-contained within their respective repositories (incubator-kie and incubator-kie-tools).
• Build scope: Yes. Each script performs a clean production build of all modules in its repository for the specified release version and commit.

[tiagobento]

Thanks @Kusuma04-dev! Love to see this moving in this direction. I have a few observations to increase clarity and reduce friction in our development/release processes.

1. The .backup files would require us to do a configuration change on Jenkins. Why not leave them as they are, and simply create new files, for new jobs? We can do like below for the new ones, and leave the old ones as they are. When we know the new jobs are working, we send a new PR deleting the files and update Jenkins to delete the old jobs.

• Jenkinsfile.103xplus.release
• Jenkinsfile.103xplus.deploy
• Jenkinsfile.103xplus.promote

---

2. We don't really have JITEXECUTOR_NATIVE anymore. You can remove those flags/configs from the new release jobs.

---

3. I don't see a Maven M2 repository in https://github.com/Kusuma04-dev/kie-release-10.3.

---

4. Can we standardize our terminology here? Release/build/publish/promote/deploy can be very confusing. I'd say we should even number (or identify with the automation letters) our scripts so that we understand exactly what order things are expected to be run.

---

5. Can we create a specific docs/RELEASING.md file here, and a repo/RELEASING.md file in kie-tools, pointing to a single source-of-truth? For the sake of democratizing our release process, I think this document should live in https://github.com/apache/incubator-kie-website under https://kie.apache.org/community/.

---

6. Is it possible to align the CLI arguments of each script between the two repos? The more in sync they are, the less friction we have during the release procedure. I'm sure they will be very similar to each other.

---

7. I see some references in the code and in comments saying "Drools unified repo", but we don't need to call it that. It's the KIE repo.

---

8. Is data-index ephemeral image tag issue still current, or is it something that is just a historical artifact from our old Jenkins automations?

[Kusuma04-dev]

Thanks @tiagobento for the review!

1. .backup files — create new files, leave old ones as-is
Done — created Jenkinsfile.103xplus.release-candidate and Jenkinsfile.103xplus.release-publish as new files, leaving all existing Jenkinsfiles untouched.

2. Remove JITEXECUTOR_NATIVE flags from new release jobs
Removed — JITEXECUTOR_NATIVE flags and GraalVM JDK for native references are not present in either new Jenkinsfile.

3. Maven M2 repository missing from kie-release-10.3
Added — the artefacts generated in local m2 are now present in https://github.com/Kusuma04-dev/kie-release-10.3/tree/main/kie_artifacts/org

4. Standardize terminology + number/letter the scripts
Done — scripts are prefixed 01–05 in both repos and automations are labelled A/D/E/F/G in release-procedure-10.3.md with consistent --rc/--publish flag naming across both incubator-kie and incubator-kie-tools.

5. repo/RELEASING.md pointing to incubator-kie-website as single source of truth
Done — Added repo/RELEASING.md in incubator-kie-tools.


6. Align CLI arguments between the two repos
Done — both repos now use the same release-all.sh --rc / --publish pattern, with incubator-kie's release-all.sh accepting --rc and --publish as aliases for parity.

7. "Drools unified repo" → "KIE repo"
Fixed — all references now say "KIE repo" and the Repositories Matrix table label has been updated accordingly.

8.data-index ephemeral image tag

It is an active mechanism for Quarkus Dev Services container image resolution.

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

6 open findings

• Parameter values are interpolated into a shell command string, which enables command injection if a… · New
• Concatenating user-provided EXTRA_MVN_OPTS into a single string and expanding it unquoted allows… · New
• mvn deploy ${DEPLOY_MVN_FLAGS[@]} is unquoted, so elements containing spaces (notably… · New
• The PR description states the new 103xplus.deploy/103xplus.promote pipelines are streamlined to… · New
• If mvn help:evaluate fails (e.g., Maven not available, POM not resolvable), CURRENT_VERSION… · New
• In dry-run mode this nests dry-run messaging (run_step already prefixes output) and prints a… · New

What changed in this PR

This PR adds local-first release automation scripts for the consolidated incubator-kie repo and introduces new Jenkins pipelines intended to delegate release activities to those scripts.

Changes:

• Added script/release/* scripts to orchestrate RC tagging, building, staging deploys, and final tag promotion.
• Added release documentation (script/release/README.md, docs/RELEASING.md) describing the new workflow.
• Added new Jenkins pipelines for 10.3.x+ release/deploy/promote flows.

File	Description
script/​release/​release-all.sh	New orchestrator for RC flow (rc-commit → build → deploy).
script/​release/​README.md	New detailed documentation for the release scripts and lifecycle.
script/​release/​01-update-version.sh	New script to update reactor Maven versions and related properties.
script/​release/​02-rc-commit.sh	New script to create R-commit and RC tag (optional push).
script/​release/​03-build.sh	New script to build the full reactor with optional test skipping.
script/​release/​04-deploy-to-staging.sh	New script to deploy artifacts to Nexus staging (dry-run by default).
script/​release/​05-tag-release.sh	New script to promote an RC tag into a final release tag.
docs/​RELEASING.md	New repo-level release guide pointing to canonical docs + local scripts.
.ci/​jenkins/​project/​Jenkinsfile.103xplus.release	New Jenkins pipeline that runs release-all.sh with parameters.
.ci/​jenkins/​Jenkinsfile.103xplus.deploy	New Jenkins pipeline for deploy-related tasks (does not call scripts).
.ci/​jenkins/​Jenkinsfile.103xplus.promote	New Jenkins pipeline for Nexus staging release (does not call scripts).

🧠 Review effort: Lite

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[Copilot]

🟡 Changes recommended

Release signing, credential handling, and final-tag targeting have unresolved correctness and security issues.

8 open findings

• Delegate releases to the local release scripts · New
• Archive the configured deployment properties filename · New
• Tag the approved RC instead of the branch tip · New
• Provide the missing file management upload script · New
• Provision Maven, GPG, Git, and push credentials · New
• Include untracked files in clean-tree validation · New
• Activate apache-release profile for signed artifacts · New
• Prevent GPG passphrase exposure in Maven arguments · New

6 resolved since last review

• mvn deploy ${DEPLOY_MVN_FLAGS[@]} is unquoted, so elements containing spaces (notably…
• Concatenating user-provided EXTRA_MVN_OPTS into a single string and expanding it unquoted allows…
• Parameter values are interpolated into a shell command string, which enables command injection if a…
• If mvn help:evaluate fails (e.g., Maven not available, POM not resolvable), CURRENT_VERSION…
• The PR description states the new 103xplus.deploy/103xplus.promote pipelines are streamlined to…
• In dry-run mode this nests dry-run messaging (run_step already prefixes output) and prints a…

Previously missed (3)

In code that hasn't changed since last review

Handle 999-SNAPSHOT as the main stream

script/​release/​01-update-version.sh:51

The documented 999-SNAPSHOT main-stream version does not match this substitution, so it remains 999-SNAPSHOT. The later property update then replaces the data-index image tag's current main value with the Maven snapshot version rather than the stream name. Handle 999-SNAPSHOT explicitly so the documented main-branch command continues selecting the main-stream image.

Restore original detached commit before deleting branch

script/​release/​02-rc-commit.sh:107

A detached checkout records the literal HEAD here. After creating the release branch, git checkout HEAD does not restore the original commit, and deleting the still-current release branch fails. This affects Jenkins SCM checkouts, which the existing pipelines explicitly handle as detached. Save the branch name when attached and the original commit SHA otherwise.

Restore detached HEAD by commit SHA

script/​release/​04-deploy-to-staging.sh:141

Starting from detached HEAD records the literal HEAD, not the original commit. After checking out the RC tag, the final git checkout "${ORIG_REF}" therefore leaves the repository at that tag instead of restoring the starting checkout. Save the branch name when attached and the commit SHA otherwise.

🧠 Review effort: Balanced

[Copilot]

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

9 open findings

• Same as the release pipeline: sshUserPrivateKey(..., keyFileVariable: 'GIT_SSH_KEY') alone… · New
• 05-tag-release.sh expects an RC tag (e.g. 10.3.0-rc2) as --rc-tag, but getGitTag() defaults… · New
• 05-tag-release.sh expects an RC tag (e.g. 10.3.0-rc2) as --rc-tag, but getGitTag() defaults… · New
• The pipeline binds an SSH private key to GIT_SSH_KEY, but git push inside… · New
• The comment claims spaces inside individual opts are preserved, but read -a with IFS=' ' does… · New
• The comment claims spaces inside individual opts are preserved, but read -a with IFS=' ' does… · New
• If --rc-tag is passed a value that doesn’t end in -rc<N> (e.g. 10.3.0), RELEASE_TAG will… · New
• The script header and Jenkins stage indicate this uploads 'Drools release binaries and… · New
• The script header and Jenkins stage indicate this uploads 'Drools release binaries and… · New

8 resolved since last review

• Prevent GPG passphrase exposure in Maven arguments
• Activate apache-release profile for signed artifacts
• Include untracked files in clean-tree validation
• Provision Maven, GPG, Git, and push credentials
• Provide the missing file management upload script
• Tag the approved RC instead of the branch tip
• Archive the configured deployment properties filename
• Delegate releases to the local release scripts

🧠 Review effort: Lite