Uh oh!
There was an error while loading. Please reload this page.
Make package generation and GPG signing optional in the CD build - #142
Closed
guanzhousongmicrosoft wants to merge 1 commit into
Closed
Conversation
Forks could not run the deployment workflow cleanly: the GPG import step ran unconditionally, so a repository without GPG_PRIVATE_KEY got a failed step on every run. The continue-on-error that hid it was also a hazard upstream, where a broken key would silently republish the site with an unsigned APT repository in place of a signed one and break apt-get update for every client pinned with signed-by. Resolve two independent feature flags up front, since the secrets context is not readable from a step-level if condition: - Package repository generation follows the BUILD_PACKAGES variable, and defaults on for this repository and off for forks, so a fork build only exercises the site and Pages publish. - Signing follows the presence of GPG_PRIVATE_KEY. When the key is absent the import step is skipped rather than failed; when it is present the import must succeed, and the artifact check now asserts that InRelease, Release.gpg and the exported keyring were produced. Document the fork workflow and both settings in the readme. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Guanzhou Song <guanzhousong@microsoft.com>
guanzhousongmicrosofthad a problem deploying
to
github-pages
August 4, 2026 02:08 — with
GitHub Actions
Failure
guanzhousongmicrosoft
commented
Aug 4, 2026
ContributorAuthor
Closing in favor of a PR from my personal account. Same change, reopening shortly. |
guanzhousongmicrosoft
deleted the
fix/optional-gpg-signing-and-packaging
branch
August 4, 2026 02:14
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 freeto 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.
Fixes#20
Problem
Setup GPGruns unconditionally in the CD build, so a fork withoutGPG_PRIVATE_KEYgets a failed step on every run. Thecontinue-on-error: truethat hides it is also a hazard upstream: if the key ever becomes invalid, the run keeps going and republishes the site with an unsigned APT repository in place of a signed one.apt-get updatethen fails for every client pinned withsigned-by, so a silently skipped signature is a user-visible outage rather than a cosmetic regression.Change
The
secretscontext is not readable from a step-levelif:, so a new first step resolves two independent feature flags into step outputs (binding the secret to that one step also keeps it out of every other step's environment):BUILD_PACKAGESvariabledocumentdb/documentdb.github.io, off in forksGPG_PRIVATE_KEYsecretcontinue-on-erroris gone, so an unusable key fails the run. The artifact check additionally assertsInRelease,Release.gpgand the exported keyring were produced. RPM metadata signing is best-effort insidedownload_packages.sh, so that one is surfaced as a warning instead of failing the deployment.Install packaging tools,Download DocumentDB packagesandVerify generated package componentsare all skipped. The static site build, docs verification, artifact upload and Pages deploy are untouched and always run.Turning packaging off upstream would publish a site with no
/deb,/rpmor keyring, so that consequence is called out in a comment next to the variable.The run summary now reports which optional halves executed and why.
Result for a fork
Enable Pages (Settings > Pages > Source: GitHub Actions), push, and the workflow builds the site and deploys it with no secrets and no red steps. Set
BUILD_PACKAGES=trueto exercise the packaging path as well.Validation
actionlintclean on both workflowsyaml-ls-checkgate passes (153 files)BUILD_PACKAGES(unset /true/false/TRUE/ invalid), upstream vs fork, and key present vs absent, including the invalid-value error pathout/rpmdirectoryrelease-info.jsonand missing per-architecture APT metadatanpm test- 129 tests pass