ci: vendor aetherpak actions to iterate on flatpak publish without cutting releases#2429
Open
kantord wants to merge 4 commits into
Open
ci: vendor aetherpak actions to iterate on flatpak publish without cutting releases#2429kantord wants to merge 4 commits into
kantord wants to merge 4 commits into
Conversation
…afely Scratch branch, not for merging to main. Vendors publish-oci, publish-site, and setup-cli locally (MIT-licensed upstream, commits pinned) so the flatpak publish + Pages pipeline from #2301 can be dry-run tested via workflow_dispatch without cutting a real release (which would trigger real auto-updates) and without the production GPG signing secrets. - setup-cli: adds SHA256 checksum verification of the downloaded CLI binary, self-verified against the actual v0.14.0 release assets (upstream has none). - publish-oci: adds a dry-run mode that skips only the actual `push-oci` registry call; everything else (import, coordinate resolution) still runs for real. - Real (non-dry-run) test pushes are isolated via a distinct "test" OCI branch (embedded directly in the image tag per pkg/oci/oci.go, cannot collide with stable/beta) and a distinct "flatpak-test" Pages subpath (isolated from the real "flatpak" path and "latest/" release manifest via destination_dir, verified against peaceiris/actions-gh-pages source). Delete this branch and file findings upstream once validation is done. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Builds the CLI from source (checked out at commit e9388a1d41021dcf0ac75feb0a2e50dba87ca81c, matching the v0.14.0 tag) instead of downloading the pre-built release binary. Pinning to an exact commit keeps this test build fully reproducible while we iterate on the pipeline, regardless of anything changing upstream in the meantime. Verified this is a straightforward build: scanned all 68 .go files at this commit, no cgo; dependencies are mainstream (go-containerregistry, cobra, ProtonMail/go-crypto) and already checksum-pinned via the upstream go.sum. Build command mirrors aetherpak/cli's own `make release/build` target, with a step confirming the checkout landed on the expected commit before building. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kantord
changed the title
kantord
marked this pull request as ready for review
July 6, 2026 17:09
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a manual, scratch GitHub Actions workflow plus temporarily vendored AetherPak composite actions to validate the Flatpak publish + GitHub Pages pipeline in a reproducible way without cutting a real release.
Changes:
- Adds a
workflow_dispatch-only “[TEMP] Test AetherPak Flatpak Publish” workflow that reuses an existing Flatpak bundle artifact from a prior workflow run. - Vendors AetherPak
setup-cli,publish-oci, andpublish-siteactions into.github/actions/_tmp-*for pinned, reproducible iteration. - Introduces a dry-run mode for the vendored
publish-ociaction to avoid mutating GHCR / Pages during validation runs.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| .github/workflows/_tmp-test-aetherpak-publish.yml | Adds a manual-only workflow to test pushing Flatpak OCI + building/deploying a site under an isolated subpath. |
| .github/actions/_tmp-aetherpak-setup-cli/action.yml | Vendored setup action that builds the AetherPak CLI from a pinned source commit. |
| .github/actions/_tmp-aetherpak-publish-site/action.yml | Vendored site-generation action that builds the static repo index (and optionally uploads a Pages artifact). |
| .github/actions/_tmp-aetherpak-publish-oci/action.yml | Vendored OCI-publish action with a dry-run mode for validation without pushing images. |
Three confirmed issues from review:
- Scratch workflow needed contents: write, not read -- peaceiris/actions-gh-pages
pushes a commit to gh-pages, which read-only permissions can't do.
- publish-site's actions/upload-pages-artifact was referenced by tag; pinned
to its commit SHA to match this repo's convention elsewhere.
- publish-oci's registry-token input defaulted to the literal expression
`${{ github.token }}`, which action.yml input defaults don't evaluate (only
outputs.*.value does, confirmed against GitHub's docs) -- a caller omitting
registry-token would get that literal string instead of a real token. This
exists upstream too. Fixed by defaulting to empty and falling back via
`inputs.registry-token || github.token` in the step's env mapping instead.
One review comment (bundle-path glob forwarded as a literal string) turned
out not to apply here: aetherpak's `import` command does call filepath.Glob
internally, and this repo's flatpak maker output is exactly one directory
level deep, which matches the `**` pattern's segment count -- verified by
reading cmd/import.go and this repo's MakerFlatpakBuilder rather than taking
the suggestion at face value.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
peppescg
reviewed
Jul 7, 2026
| @@ -0,0 +1,285 @@ | |||
| # ============================================================================ | |||
| # TEMPORARY VENDORED COPY — DO NOT MERGE TO main | |||
Collaborator
There was a problem hiding this comment.
I don't understand do you wan to merge this pr on main 🤔 ?
peppescg
reviewed
Jul 7, 2026
| - name: Push Flatpak OCI to GHCR (test channel, unsigned, dry-run capable) | ||
| uses: ./.github/actions/_tmp-aetherpak-publish-oci | ||
| with: | ||
| bundle-path: _bundles/**/*.flatpak |
Collaborator
There was a problem hiding this comment.
This glob will never match, so the first run should fail at the "Import bundle" step.
The chain:
pr-build-test.ymluploads withpath: out/make/**/*.flatpak.upload-artifactpreserves the directory structure after the first wildcard, so the artifact containsflatpak/<arch>/<name>.flatpak.- Downloaded into
_bundles, the file lands at_bundles/flatpak/<arch>/<name>.flatpak— three levels below_bundles. - The action passes the pattern through to
aetherpak import --bundle-path, which resolves it with Go'sfilepath.Glob(cmd/import.go at the pinned commit). Go's glob has no globstar:**behaves like*and matches a single path component, so_bundles/**/*.flatpakonly matches files exactly two levels deep. - Zero matches →
cmd/import.gofalls back to the literal pattern as a path → import fails on a nonexistent file.
Most robust fix is to resolve the path in the workflow instead of relying on the CLI's glob:
- name: Resolve bundle path
id: bundle
run: echo "path=$(find _bundles -type f -name '*.flatpak' | head -1)" >> "$GITHUB_OUTPUT"then bundle-path: ${{ steps.bundle.outputs.path }}. (Alternatively _bundles/*/*/*.flatpak matches the current artifact layout, but it's brittle if the upload path changes.)
…ring plan These files are meant to be merged, not left as pure throwaway scratch code -- the point is to decouple the flatpak publish + Pages pipeline from tagged releases so it can be iterated on without cutting real ToolHive Studio releases (which trigger real auto-updates and binary signing) just to test changes here. The old banners said the opposite and confused reviewers. Also trimmed the internal contingency language (upstreaming vs. staying vendored long-term) -- that's our own planning, not something that needs to live in a public repo file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kantord
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Vendors the
setup-cli,publish-oci, andpublish-siteactions from #2301, pinned to a specific source commit, so we can iterate on the flatpak publish + Pages pipeline in follow-up PRs without cutting real ToolHive Studio releases just to test changes here.Fully or partially written by an AI agent.