EN Testing and Publishing - AlanDevise/TsGate GitHub Wiki
2.1.3 is published through the GitHub source/tag and Maven Central; same-SHA CI and public artifact verification passed. Current coordinates: 2.1.3; see 2.1.3 release notes.
TsGate 2.1.3 publication and verification
The frozen implementation passed local prerelease verification: 1,476 unit checks on each of JDK 17/21/25, 323 Docker integration checks and 83 Python checks, with zero failures/errors/skips and successful owned-resource cleanup. The 166-input source manifest and implementation diff were checked before release preparation. These are the earlier local prerelease results, not newly executed 2.1.3 JDK 21/25 or Docker runs.
Final source 18fccb6 and tag v2.1.3 are pushed. Its fresh signed Temurin 17 build passed 1,476 unit checks. The release audit passed for nine JAR modules, 27 JARs / 11 POMs, 38 valid signatures and 228 signed-bundle entries; the credential scan passed. Bundle SHA-256: e192aec3177c6cb5ab2dd9cd4d6a61b31a6c8c2f01e7a0f921d599d90612bb3f. Same-SHA tag CI passed all 9 jobs, including 1,476 unit checks on each of JDK 17/21/25 and 323 Docker integration checks. Central is PUBLISHED; all 38 primary artifacts and 38 published signatures were downloaded from the public Maven repository and matched the signed bundle by SHA-256.
The test-only tsgate-core/src/test/resources/ci/backend-registration.json and portable tsgate-core/src/test/scripts/verify-backend-registration.py cross-check actual module activation, starter imports, BOM, shared contracts, Docker/CI coverage and artifact inventory. Run python3 tsgate-core/src/test/scripts/verify-backend-registration.py from the repository root. The common runner invokes this gate before Maven or Docker setup; existing CI Python discovery exercises valid and incomplete registrations. This adds no production registry or SPI.
TsGate 2.1.2 GitHub-only release
Version 2.1.2 final-source local verification passed: three JDK suites of 1,233 cases, 304 Docker test executions, 71 Python cases, actionlint and the 27-JAR/11-POM unsigned audit; the full-JAR mapping benchmark is complete. The source and annotated v2.1.2 tag are pushed. Main CI and tag CI each passed all 9 jobs, with downloaded original reports, source identity and cleanup verified. Main covers two OpenGemini single nodes (92 cases); tag covers all four deployments (184); each also passes three 1,233-case JDK suites and 120 representative Docker tests. Distribution uses GitHub source/tag plus the package and reports and synchronized bilingual Wiki. No signing, Central upload or deployment was performed for 2.1.2; Maven Central was at 2.1.0 at that time. Install the aligned source locally before using 2.1.2 Maven dependencies. Full evidence is in 2.1.2 release notes; older publication records below remain historical.
TsGate 2.1.1 GitHub-only release
Version 2.1.1 is released through the GitHub tag/release. No Central upload or publication is performed for this version; the latest publicly resolvable Central release at that time was 2.1.0. Source installation with mvn clean install supplies aligned local 2.1.1 parent/BOM/modules, as shown in Getting started.
The unchanged eleven-module layout produces nine binary, nine source and nine Javadoc JARs when the unsigned release-artifacts profile is used. Building/verifying those attachments and publishing a GitHub release are separate from the Central procedure documented later for future authorized publications. The 2.1.1 release notes record this release's actual tests, source identity and artifact evidence; the 2.1.0 records below remain historical.
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 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.
Shared adapter contract checks
The ordinary unit command also executes each backend's *SharedAdapterContractTest, backed by the reusable core test interface and adapter-capabilities.csv. Registry tests keep backend entries and contract classes complete. Common assertions verify query/count preflight, configuration snapshots, terminal lifecycle, confirmed/unknown batch boundaries, exact timestamps and pagination lookahead. Backend-specific tests retain dialect and HTTP error distinctions; capability rejection is an assertion, not a skip. Version/configuration prerequisites are separate explicit checks, not production feature detection.
Backend selection in 2.1.1
Omitting selectors preserves the representative IoTDB / InfluxDB 1.x / InfluxDB 3 scope. Select only a relevant backend when investigating a backend-local change:
python3 tsgate-core/src/test/scripts/run-tests.py docker --backend iotdb --spring-boot 2.7.18
python3 tsgate-core/src/test/scripts/run-tests.py docker --backend influxdb1 --spring-boot 2.7.18
python3 tsgate-core/src/test/scripts/run-tests.py docker --backend influxdb --spring-boot 2.7.18
influxdb selects InfluxDB 3. A subset run explicitly reports omitted backends; its success must not be presented as a complete matrix pass. Each runner owns only the containers it creates and records cleanup and failures. Preserve fresh report directories and source manifests when comparing results.
OpenGemini's exact-version runner keeps its default full four-deployment matrix. The new mode selector permits routine single-node checks or a targeted cluster rerun:
python3 tsgate-opengemini/src/test/scripts/run-matrix.py --mode single --output .local-test/opengemini-single
python3 tsgate-opengemini/src/test/scripts/run-matrix.py --mode cluster --output .local-test/opengemini-cluster
python3 tsgate-opengemini/src/test/scripts/run-matrix.py --output .local-test/opengemini-full
Both single and cluster cover exact versions 1.4.1 and 1.5.2 in the selected topology. The default includes both topologies, with three replicas for each real three-node cluster. Image reuse retains exact-version provenance verification; selecting a smaller scope does not broaden compatibility claims.
For 2.1.2 owned three-replica runs, the runner automatically passes absolute fixture script/state paths. After CREATE DATABASE, adapter and starter tests invoke a read-only initial data-Raft gate before their first write, with a 45-second deadline. Version 1.5.2 uses scoped database/partition finishes; official-binary 1.4.1 uses a pinned complete startup-log transfer ledger, explicit target partitions and two stable observations. Missing or incompatible evidence fails the gate. This controlled serial fixture observation is not an atomic or continuous health guarantee; see version-specific mechanism and limits. Single-node tests do not require this gate. Cluster membership/meta health and new-series query visibility are separate readiness conditions. This preparation does not alter server parameters, issue warmup writes or add production write retries.
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-replicas 1
This portable external-endpoint command covers a single node with replication count 1. It creates isolated test databases and verifies template/native readback; the shared runner does not start or remove the external server. The 2.1.2 three-replica integration suite requires the dedicated run-matrix.py owned fixture and its absolute script/state properties, supplied by that runner automatically. External cluster URLs alone cannot run this test setup because its read-only gate needs exact per-database evidence from all owned store logs. This is a test prerequisite: production adapters still support external three-replica clusters without Docker/log access. See the dedicated guide for the full matrix and provenance.
GitHub Actions
The CI workflow retains JDK 17 / Boot 2.7.18, JDK 21 / Boot 3.5.14 and JDK 25 / Boot 4.1.0 unit checks and the Java 17 unsigned archive audit. Relevant pull requests and pushes automatically select representative Docker checks by changed source paths: adapter-module changes cover the corresponding backend, core/shared build inputs and starter changes cover all backends, and InfluxDB 1.x adapter changes also cover its OpenGemini consumer. A missing or unavailable comparison diff conservatively selects full coverage. Routine OpenGemini CI covers both exact versions as single nodes; release tags and full manual runs cover single nodes and three-node/three-replica clusters for both versions.
Runner scope is explicit in reports. CI retains exact-version image/dependency caching, bounded execution, cancellation of superseded runs and unconditional owned-resource cleanup/failure-log collection. Release evidence must identify the same source SHA and show no failures, unexpected skips or cleanup failures. Configuring workflow jobs does not itself make them required branch-protection checks. Current release results and the actual remote run are recorded in 2.1.3 verification evidence; historical results below keep their original source scope.
The historical 2.1.0 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.alandevisenamespace. 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-soption. 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 release changes.