EN Testing and Publishing

Home · GitHub

English | 简体中文

TsGate 2.1.0: This guide uses com.alandevise.tsgate.*. Upgrading from 2.0.0 requires updating imports, reflection names and package scanning, then recompiling. Central 2.0.0 retains com.alandevise.tsdb.*. See migration steps and release status.

2.1.0 artifact set

TsGate 2.1.0 adds tsgate-opengemini and tsgate-opengemini-spring-boot-starter, bringing the build to four backends and nine JAR modules. The 2.1.0 BOM manages both new modules. Central 2.0.0 contains neither module. See OpenGemini integration for the exact verified default-engine versions and topologies. Version 2.1.0 produces 27 JAR attachments (nine binary, nine sources and nine Javadoc). Published 2.0.0 and the historical validation snapshot below retain seven JAR modules / 21 JAR attachments. Compilation and packaging do not upload or publish a release.

TsGate 2.1.0 release status

TsGate 2.1.0 is published to Maven Central. Deployment 10fe41e4-7cf7-45a6-bab1-f2b1e6098430 reached PUBLISHED on 2026-10-03 (Asia/Shanghai). The released source commit 8cf119e is tagged v2.1.0; the separate namespace migration commit 2cecd41 preserves the history of all 91 existing Java files.

The release contains eleven Maven modules: the parent POM, standalone BOM and nine JAR modules. All 38 primary artifacts (eleven POMs and 27 binary/source/Javadoc archives) were downloaded from the public Maven repository; every SHA-256 matched the signed upload. All 38 PGP signatures and four checksum types were verified before upload. The final release source also passed GitHub CI for JDK 17/21/25; exact local unit and Docker results are in Compatibility and validation.

Published coordinates use groupId io.github.alandevise and version 2.1.0: BOM · OpenGemini starter. Public signing-key fingerprint: D7FB5E1158537706FB2023D62DCFFB6B26BE7EB5. Signed bundle SHA-256: b6cbc4927587223bfbad9b613c63cf0894e1f014571368db8de4d4ce580c1193. The historical 2.0.0 publication record below remains unchanged.

Running tests

Portable test sources and reusable configuration are committed under each module's src/test/. Local reports, machine-specific fixtures and credentials remain ignored under .local-test/. Run from the repository root with Java 17+, Maven 3.9+ and Python 3; Docker is required for integration tests:

python3 tsgate-core/src/test/scripts/run-tests.py unit --spring-boot 2.7.18
python3 tsgate-core/src/test/scripts/run-tests.py unit --spring-boot 2.7.18 --release-artifacts
python3 tsgate-core/src/test/scripts/run-tests.py docker --spring-boot 2.7.18

Select the JDK with JAVA_HOME. Use --offline --maven-repo /path/to/cache with a complete dependency cache, or --pull never to reuse existing database images. Reports are written to a fresh .local-test/ci/ directory; --output can select another new directory. See compatibility and validation for exact database versions, runtime combinations and test boundaries.

OpenGemini external Docker endpoints

Without --opengemini-url, the representative Docker runner keeps its existing three-database coverage and explicitly excludes OpenGemini*DockerIT; the JSON report records the exclusion. This is not an openGemini regression result. Provide an existing deployment to include its portable tests:

python3 tsgate-core/src/test/scripts/run-tests.py docker --spring-boot 2.7.18 \
  --opengemini-url http://127.0.0.1:8086 --opengemini-version 1.5.2 \
  --opengemini-urls http://127.0.0.1:8086,http://127.0.0.1:18086,http://127.0.0.1:28086 \
  --opengemini-replicas 3

For a single node, omit --opengemini-urls and use replication count 1 (the default). These options only target external servers; the shared runner does not start or remove them. Cluster URLs must belong to the same cluster. The tests create isolated databases with the specified replication count, write through every SQL entry and verify template/native readback. Actual release and cluster membership evidence remain separate from HTTP compatibility. See the dedicated guide for the four-topology matrix and fixture provenance.

GitHub Actions

The CI workflow runs JDK 17 / Boot 2.7.18, JDK 21 / Boot 3.5.14 and JDK 25 / Boot 4.1.0 unit combinations on matching source changes and pull requests. All jobs select the temurin distribution. The Java 17 release job verifies that the runtime reports java.vendor = Eclipse Adoptium and java.specification.version = 17, runs the artifact verifier's regression tests, and builds and inspects unsigned release artifacts, including generated third-party license materials. The workflow uses read-only repository permissions, pinned action revisions and seven-day report retention. Run representative Docker regression manually with workflow_dispatch and run_docker=true.

The final release source commit 8cf119e passed all three JDK / Spring Boot combinations in GitHub Actions, including the Java 17 unsigned release artifact audit. This run did not request remote Docker; the release's 290 local Docker test executions are recorded in the compatibility guide.

Building release artifacts

Use Eclipse Temurin 17.0.14+7, Maven 3.9+ and Python 3 for release builds. Select the Temurin installation explicitly so Maven and Javadoc use the same toolchain:

export JAVA_HOME=/path/to/temurin-17.0.14+7
export PATH="$JAVA_HOME/bin:$PATH"
java -version
mvn -version
mvn -Prelease-artifacts clean verify
python3 scripts/verify-release-artifacts.py --project-root . \
  --output .local-test/release-artifacts.json

This selects the distribution used to produce release attachments; the library's Java 17 baseline remains unchanged. The 2.1.0 unsigned build generates nine binary JARs, nine source JARs and nine Javadoc JARs, including LICENSE/NOTICE materials, plus the parent and standalone BOM POMs. Javadoc uses delomboked sources so generated public members have working links. Ordinary JARs and source attachments contain production material and exclude test classes, fixture credentials and local reports.

Keep the Javadoc generator's legal/ directory and the copyright/license headers on generated JavaScript and stylesheet resources. Those third-party materials retain their own licenses; TsGate's Apache-2.0 LICENSE and NOTICE cover project-owned code. The artifact verifier checks all 27 release JAR archives, including required third-party Javadoc license files, and rejects Oracle proprietary/confidential or OTN license markers. Do not remove notices or rewrite license headers to make a failing artifact pass; rebuild it with the selected Temurin toolchain.

Publishing to Maven Central

The central-release profile adds PGP signing and the Central Portal publishing plugin. It keeps uploads disabled by default with central.skipPublishing=true and uses autoPublish=false. Uploading, passing Portal validation and publishing a release are separate steps.

Before uploading, configure:

• A Central Portal account with the verified io.github.alandevise namespace. The namespace corresponds to the maintainer's GitHub identity. Namespace verification
• Portal publishing-token credentials in a local Maven settings file, with a server whose id is central. Keep the settings file and actual token values outside Git, and pass the file path with Maven's -s option. Portal publishing tokens differ from GitHub tokens. Portal tokens
• A maintainer-controlled PGP signing key and retrievable public key. Keep private key material and passphrases in secure local storage or CI secrets. Signing requirements
• Final coordinates/version, developer and SCM metadata, the complete parent/BOM/module artifacts, source/Javadoc attachments, signatures and checksums. Central requirements

With those prerequisites configured and the same Temurin 17 toolchain selected, build and inspect the signed release before uploading. The first command retains the default central.skipPublishing=true:

mvn -s /path/to/settings.xml -Pcentral-release clean verify
python3 scripts/verify-release-artifacts.py --project-root . \
  --output .local-test/signed-release-artifacts.json

mvn -s /path/to/settings.xml -Pcentral-release deploy \
  -Dcentral.skipPublishing=false

autoPublish=false uses a user-managed deployment and leaves a validated deployment in the Portal for manual publication. Record the source commit and deployment outcome for the release. When replacing an unpublished deployment, retain its identifier in local records, upload and validate the rebuilt and re-signed bundle, then remove the superseded pending deployment from the Portal. Do not overwrite an already published version. An offline invocation or skipPublishing=true does not upload, and unsigned diagnostic builds do not satisfy Central's signing requirements. See the Central Maven plugin.

TsGate 2.0.0 upload verification

The replacement 2.0.0 bundle was rebuilt and signed with Eclipse Temurin 17.0.14+7 on September 29, 2026. The clean release build passed 638 unit tests, with zero failures, errors or skips. All 21 JARs passed the project-license and generated-resource audit. Each Javadoc JAR retains all five generator-provided notice files under legal/: LICENSE, ADDITIONAL_LICENSE_INFO, ASSEMBLY_EXCEPTION, jquery.md and jqueryUI.md. These preserve the OpenJDK GPLv2 with Classpath Exception and the applicable third-party MIT notices. All 28 Oracle proprietary/OTN markers present in the original artifacts are absent from the replacement bundle.

The bundle contains nine modules (the parent, BOM and seven JAR modules). All 30 PGP signatures and four checksum types were independently verified. Its 78 compiled classes, 45 Java source files and nine POMs are byte-for-byte identical to the preceding upload; the rebuild does not change adapter behavior or dependencies.

TsGate 2.0.0 is published to Maven Central. Deployment 8e8970f0-14c9-4e5c-97af-3ed9270bce57 reached PUBLISHED after manual publication on September 29, 2026. All nine POMs and the core JAR were downloaded from the public repository and their SHA-256 hashes matched the signed upload. Published BOM.

Public signing-key fingerprint: D7FB5E1158537706FB2023D62DCFFB6B26BE7EB5. The RSA4096 signing key expires on September 28, 2028 UTC. Retrieve the public key from Ubuntu keyserver to verify release signatures.

OpenGemini in 2.1.0

TsGate 2.1.0 includes the independent OpenGemini adapter and starter. See OpenGemini integration for configuration, default-engine limits and exact-version testing, and 2.1.0 release notes for migration requirements.