The Release p2 and server distributions workflow builds the published release tag with Java 21 and the Maven wrapper. Before uploading assets, it runs the API contract, server unit and packaged HTTP/restart acceptance, browser tests, Linux/Xvfb Eclipse/Jira tests, and installed remote Eclipse acceptance with the browser peer and real GTK file/folder dialogs. The server ZIP used by both clients is built from that same tag and includes the web client. The job validates the p2 metadata, artifact inventory, both checksums and shared source identity, then attaches:
timekeeper-p2.zip: an Eclipse p2 repository, with metadata at the archive root;timekeeper-p2.zip.sha256: its SHA-256 checksum;timekeeper-server.zip: the complete Java 21 server distribution, including the web client;timekeeper-server.zip.sha256: its SHA-256 checksum.Credential-free test reports and acceptance receipts are retained as the
release-test-results workflow artifact, including all installed restart/account/
backend phases. See server installation and
web client for configuration.
The archive contains timekeeper-release.json with the release tag, source
commit and qualified p2 feature version. The job builds the tag, not the current
main branch. Use a tag matching the plugin version, such as v2.0.0 or
v2.0.0-rc.1. Publishing a draft triggers the job; editing or saving a draft does
not. Both stable releases and published prereleases are supported.
In repository Settings > Pages > Build and deployment, select GitHub
Actions as the source. The github-pages environment must allow deployments
from the default branch. The existing project website continues to be built
with GitHub’s Jekyll action; generated p2 repositories are added after Jekyll,
so binary metadata and JARs are served without transformation.
The Website and p2 update site workflow runs after successful main Build and Server containers workflows, p2/server and Synology release workflows, release edits/deletions, and manual dispatch. It always checks out the default branch. After a main Build it fetches that run’s prepared site; other triggers reconstruct the site from published release assets and the latest qualifying main build. Drafts and historical releases without the new asset pair are excluded. Checksums, embedded release identity, feature version and the artifact inventory must validate before a Pages deployment can proceed. Failed builds or invalid assets leave the previously deployed site intact.
Install locations:
| Location | Contents |
|---|---|
https://turesheim.github.io/eclipse-timekeeper/updates/testing/ |
Latest available main build that passed the complete platform/server/web/installed-client workflow; unreleased |
https://turesheim.github.io/eclipse-timekeeper/updates/ |
All stable releases; p2 selects the newest compatible version |
https://turesheim.github.io/eclipse-timekeeper/updates/preview/ |
Published prereleases only |
https://turesheim.github.io/eclipse-timekeeper/updates/releases/<tag>/ |
One release’s original p2 repository |
The testing channel comes from the successful main workflow’s p2-repository
artifact. Pages rejects PR/fork runs and requires all three platform jobs,
API, Server, Web, Packaging and channel tests, Build website and update site and
Installed client tests to pass. Older verified workflows used the name
Publication, Publication tooling tests and Update site checks. The publisher verifies
the artifact’s run/source identity and GitHub SHA-256 digest, then validates p2
metadata and every declared plugin/feature file. timekeeper-build.json records
the commit, version, run and artifact checksum. The testing repository has a
build/artifact-specific path; stable and preview channels remain release-only.
Packaging and channel tests runs unit tests of our Python packaging, checksum, p2 metadata, channel selection and documentation-link code in parallel. These are tests of this repository’s tooling.
For code changes, Build website and update site depends on the complete build matrix, API,
server, web, installed-client and tooling jobs. It builds the documentation
with Jekyll, verifies and downloads p2-repository from that same run, adds
the testing repository and published release channels, and uploads the complete
website-update-site artifact on main pushes. timekeeper-site.json records
its source/run and p2 identity. Code builds do not substitute a previous main build.
Select validation jobs compares a PR with its merge base, or a main push
with its previous head. If every changed path is a Markdown file or under
docs/, the platform matrix, API, server, web, installed-client and container
jobs are skipped. Only the small packaging/channel tests and website assembly
run. Documentation publication reuses the latest available fully tested main
p2 artifact and released channels; it does not create or promote new binaries.
The site receipt records the new documentation commit/run separately from the
retained p2 commit/run. Pages retains that prepared documentation and p2 content,
then appends separately verified Synology distribution channels.
Tags, manually dispatched container builds, mixed code/documentation changes,
workflow changes and unavailable diff history retain full validation.
A main push starts Build. Pages waits for the complete successful workflow;
there is no separate immediate push deployment. Its workflow_run trigger
deploys only a completed main build that still matches the default-branch head
when the event arrives, so an older build finishing later is skipped. It
downloads that exact prepared website artifact, checks its GitHub SHA-256,
source identity and complete p2 repository, and deploys it through Publish
website and update site. The documentation and binaries are not rebuilt on
that path. Release edits, release-workflow completion and explicit manual
dispatch still reconstruct the release channels from verified assets and the
latest qualifying main p2 build. Failed, documentation-only or PR builds cannot advance testing.
If no qualifying unexpired artifact exists, its page explains that no testing
build is available. It does not substitute an unchecked candidate. Action
artifacts have finite retention; rerun main Build to repopulate an expired test
channel. Publishing tested main builds does not publish a GitHub release or
complete final release acceptance.
The channels are p2 composite repositories pointing to retained release directories. New prereleases cannot update the stable channel. Promoting a prerelease without a suffix to a stable release updates the channels when the release is edited; tags containing a prerelease suffix always stay in preview. Keep the assets attached to older releases to retain their installation URLs and artifact resolution. Deleting a release removes it on the next deployment. The GitHub Pages site size limit applies to the sum of retained repositories.
If the build fails, use Actions > Release p2 and server distributions > Run workflow on main with the already published release tag. An existing complete set of all four assets is downloaded and verified for checksums, release tag and matching source commits before reuse; assets are never overwritten. The Pages workflow also verifies the p2 repository before deployment. If an upload was interrupted, restore the missing files from the original successful build or remove the partial set before retrying. A p2 pair alone cannot count as a completed 2.0 release. Existing historical p2-only releases remain usable by the Pages builder. Rebuilding uses new qualified p2 versions, so do not overwrite an already distributed repository at the same release URL. Publish a new release instead.
To rebuild only the website/channels, manually run Website and p2 update
site on main. No personal access token or separate hosting secret is required:
the release job uses contents: write; Pages deployment uses pages: write
and id-token: write through the repository’s GITHUB_TOKEN.
Synology release packaging uses a separate Release Synology distribution
workflow. It promotes the exact main candidate tested on the NAS, requires the
complete matching matrix/container runs and operator acceptance report, and
attaches the SPK/checksum/provenance/publication evidence without rebuilding.
Pages validates those release assets before creating a stable DSM catalog. The
preview DSM catalog is disabled until an operator enables
SYNOLOGY_PREVIEW_ENABLED after manual NAS installation; it can then use only
verified main candidates with a matching full matrix. These channels do not
change Eclipse’s p2 channel selection. See the Synology distribution guide
for exact source URLs, manual acceptance, release inputs and the remaining real
DSM discovery checks. No automatic publication substitutes for those checks.
python3 -m unittest discover -s scripts/tests -v
actionlint .github/workflows/build.yml .github/workflows/release-p2.yml .github/workflows/release-synology.yml .github/workflows/pages.yml
python3 scripts/p2_release.py package \
--repository eclipse/net.resheim.eclipse.timekeeper-site/target/repository \
--tag v2.0.0 --commit "$(git rev-parse HEAD)" --output /tmp/timekeeper-release
The packaging command validates an existing build; run the normal clean
./mvnw ... verify first to create it. With authenticated gh available,
python3 scripts/p2_release.py site --repo turesheim/eclipse-timekeeper --output /tmp/timekeeper-site --include-testing
reconstructs the update repositories locally without uploading or publishing.
The workflow uses GitHub’s custom Pages deployment and Eclipse’s p2 composite repository format.