Drop dead Jenkins/Appveyor/SourceForge autobuild infrastructure

[Vest]

Summary

PCGen has been released exclusively through GitHub Actions for some time. A lot of the surrounding code/gradle/ machinery — and one orphan appveyor.yml — is left over from the Jenkins / SourceForge / BUILD_NUMBER era and is never exercised. This PR removes that dead surface in five focused commits.

The release pipeline itself is untouched: pcgenRelease and updateVersionToNext (the only Gradle release tasks any workflow actually invokes) and the gradle-release.yml / gradle-release-manual.yml / gradle-nightly.yml workflows all keep working. Verified by configuring the build (./gradlew help --task pcgenRelease) and recompiling (./gradlew compileJava) after each commit. Net ~440 lines removed across the five commits.

Why each item is dead

1. Jenkins / Appveyor / SourceForge autobuild plumbing (commit 1)

• appveyor.yml — Java 11 matrix on a Java 25 project, last meaningfully touched 2026-02-26 only as a drive-by inside an unrelated PR. No README, doc, or workflow references it.
• BUILD_NUMBER-gated branches in autobuild.gradle and distribution.gradle — Jenkins set this env var, GitHub Actions does not. The active branch wrote artifacts to /home/pcgen1/public_html/autobuilds/ on SourceForge.
• code/gradle/autobuild.template — the autobuild.properties template the above branches expanded; nothing else read it.
• Runtime side: with autobuild.properties no longer produced, the Java branches that read it are unreachable too. Removed PCGenPropBundle.autobuildProperties field, its static loader, and getAutobuildNumber/getAutobuildDate/getAutobuildString; the " autobuild #N" suffix in Main's startup log; the isNotBlank(getAutobuildDate()) / isNotBlank(getAutobuildNumber()) branches in AboutDialogController. Orphaned imports go with them.
• Doc fixup: faqcommunity.md pointed at pcgen.sourceforge.net/autobuilds/pcgen-docs/ (404). Repointed at the GitHub docs/ tree.

2. The buildDist zip chain and autobuild.gradle itself (commit 2)

After commit 1, no consumer remains for autobuild.gradle or the five-zip distribution flow it fed:

• autobuild.gradle (the copyDocs / copyDist / copySite / copyInstaller / deployAutobuild chain) was the entire purpose of those tasks.
• buildDist and its dataZip / docsZip / programZip / libsZip task registrations in distribution.gradle had exactly one external invocation: appveyor.yml:16, which commit 1 deleted. No GitHub workflow ever called buildDist. The libsDistsImage and zipRootFolder ext properties only fed those tasks.
• Updated the distZip { enabled = false } / distTar { enabled = false } comment in build.gradle — the previous comment said the suppression was needed because "CI publishes the custom buildDist zips instead", which is no longer accurate. The suppression itself is kept (otherwise the application plugin would materialize ~150 runtime JARs into build/distributions/ on every build); reason updated to "jpackage installers are what CI publishes".

The four *DistsImage copy specs that feed applicationDistribution.with(...) are kept — that path is consumed by installDist → jpackage's input directory and is on the active release path.

3. Orphan code/gradle/config.ini and code/gradle/site/ (commit 3)

After commit 2:

• code/gradle/site/{download,index}.html was uploaded by autobuild.gradle::copySite to the SourceForge autobuild site. Last touched 2017 in Admin 44 #2381 ("Admin 44 ... installer ... deployAutobuild"). With autobuild.gradle gone, nothing references the directory.
• code/gradle/config.ini had zero references anywhere — no .gradle, .java, .yml, .xml, .html, .template, or .md file points at it. It is distinct from the runtime user-settings /config.ini at the repo root that pcgen.system.ConfigurationSettings reads from CWD; that one is untouched. Last touched 2015-05-17 (line-ending normalization) — a decade-old orphan template.

4. Dead release tasks: pcgenReleaseOfficial and releaseNotes ext (commit 5)

Audited every task and ext in release.gradle for consumers. Three items had none and went with their dependency chain:

• pcgenReleaseOfficial task — added in 2017 (add pcgenReleaseOfficial #2931), never wired into any workflow or other Gradle file. Only invoker would be a manual ./gradlew pcgenReleaseOfficial command, which the release workflow does not run.
• updateVersionRelease task — only consumer was pcgenReleaseOfficial.
• unSnapshotVersion() in releaseUtils.groovy — only consumer was updateVersionRelease.
• releaseNotes ext + the shortVerNum ext that derived it — releaseNotes built a path string into ${projectDir}/installers/release-notes/pcgen-release-notes-<verNum>.html, but no task, jpackage configuration, or other Gradle code ever read it. Updated the plainVerNum comment in build.gradle to mention only its remaining consumer (jpackage's appVersion derivation).

Kept everything still wired to a workflow — see the next section.

How releases work after this PR

Releases are driven by gradle-release-manual.yml (workflow_dispatch). The release version is supplied as an input, e.g. 6.09.08 or 6.09.08.RC1. Tags are created by the workflow, not consumed as input — the operator does not pre-create a tag.

End-to-end flow:

1. Trigger: operator runs the workflow with release_version=6.09.08 (no v prefix, no -SNAPSHOT suffix; the workflow validates this).
2. Tag freeness check: workflow verifies vX.Y.Z is not already taken on the remote.
3. Bump-to-release: workflow seds version= in gradle.properties to the requested release version (no -SNAPSHOT), commits as Release v<version>, and pushes to the dispatched branch. This is plain sed in the workflow — there is no Gradle helper involved at this step. The deleted unSnapshotVersion() was never part of this path.
4. Tag: workflow tags the release commit vX.Y.Z and pushes the tag, which creates the GitHub Release and uploads the per-platform jpackage installers + portable zips assembled by pcgenRelease.
5. Build: each matrix job runs ./gradlew build compileSlowtest datatest pfinttest pcgenRelease. pcgenRelease → prepareRelease (build) + assembleArtifacts (sourcesJar + fullJpackage + portableZip into releaseDir) — all kept.
6. Bump-to-next-dev (only on success): a final job runs ./gradlew --no-daemon --no-configuration-cache updateVersionToNext, which calls updateVersion() in releaseUtils.groovy (kept) — increments the trailing numeric token by one, zero-padded, and appends -SNAPSHOT. Workflow commits the result back to the dispatched branch as Bump to next dev version.

The companion gradle-release.yml (workflow_dispatch with a tag input) is the manual re-build path: an operator supplies a pre-existing tag and the workflow validates that gradle.properties's version matches the tag, then runs the same pcgenRelease build. This is for re-issuing a build off an existing tag without bumping versions.

gradle-nightly.yml runs the same pcgenRelease invocation on a schedule, tagging v<base>-NIGHTLY.<YYYYMMDD> and pruning older nightlies.

So tags are central: the manual workflow creates them on success, the rebuild workflow validates against them, and nightly creates dated ones. The Gradle side only handles two version-bump operations (the workflow does the strip-to-release with sed, and updateVersionToNext does the bump-to-next-dev), and only the second one is still needed in releaseUtils.groovy.

What's kept

Everything still reachable from a workflow:

Task / file	Used by
pcgenRelease, prepareRelease, assembleArtifacts, sourcesJar (release.gradle)	gradle-release.yml, gradle-release-manual.yml, gradle-nightly.yml
updateVersionToNext (release.gradle)	gradle-release-manual.yml bump-to-next-dev step
updateVersion() helper (releaseUtils.groovy)	updateVersionToNext
dataDistsImage, docsDistsImage, programScriptImage, charactersImage (distribution.gradle)	applicationDistribution.with(...) → installDist → jpackage
distribution.gradle, plugins.gradle, release.gradle, releaseUtils.groovy, reporting.gradle	All applied from build.gradle and load-bearing
distZip / distTar enabled = false block	Still suppresses an application-plugin behaviour (~150 runtime JARs) we don't want

Test plan

• ./gradlew compileJava clean after each commit
• ./gradlew :test --tests pcgen.gui3.dialog.AboutDialogTest passes (the only test directly exercising the touched UI code)
• ./gradlew help --task pcgenRelease and --task updateVersionToNext resolve
• ./gradlew help --task pcgenReleaseOfficial correctly reports the task is gone
• CI: full build green
• First post-merge release on master is the operational verification — the workflow does not change here, only dead Gradle helpers behind it disappear

[Vest]

@karianna , I know, there is much text. It is more for the reporting reasons, why I need this PR. I think, many files were dead, and we don't need them to prepare the release.
So I asked bot to describe steps, how the release might work.

[karianna]

I'll hold off on this one until we're really sure we can do an 'official' release from the GH Actions