Skip to content

Make package generation and GPG signing optional in the CD build - #142

Closed
guanzhousongmicrosoft wants to merge 1 commit into
documentdb:mainfrom
guanzhousongmicrosoft:fix/optional-gpg-signing-and-packaging
Closed

Make package generation and GPG signing optional in the CD build#142
guanzhousongmicrosoft wants to merge 1 commit into
documentdb:mainfrom
guanzhousongmicrosoft:fix/optional-gpg-signing-and-packaging

Conversation

@guanzhousongmicrosoft

Copy link
Copy Markdown
Contributor

Fixes#20

Problem

Setup GPG runs unconditionally in the CD build, so a fork without GPG_PRIVATE_KEY gets a failed step on every run. The continue-on-error: true that 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 update then fails for every client pinned with signed-by, so a silently skipped signature is a user-visible outage rather than a cosmetic regression.

Change

The secrets context is not readable from a step-level if:, 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):

FlagControlled byDefault
Package repositoriesBUILD_PACKAGES variableon in documentdb/documentdb.github.io, off in forks
Package signingGPG_PRIVATE_KEY secretoff when the secret is unset
  • Signing absent - the GPG import step is skipped rather than failed, and a workflow warning notes the repositories will be unsigned.
  • Signing present - continue-on-error is gone, so an unusable key fails the run. The artifact check additionally asserts InRelease, Release.gpg and the exported keyring were produced. RPM metadata signing is best-effort inside download_packages.sh, so that one is surfaced as a warning instead of failing the deployment.
  • Packaging off - Install packaging tools, Download DocumentDB packages and Verify generated package components are 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, /rpm or 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=true to exercise the packaging path as well.

Validation

  • actionlint clean on both workflows
  • The repository's own yaml-ls-check gate passes (153 files)
  • Flag resolution exercised across 7 combinations of BUILD_PACKAGES (unset / true / false / TRUE / invalid), upstream vs fork, and key present vs absent, including the invalid-value error path
  • The verification block tested against fixtures for signing-disabled, signing-enabled-with-missing-signatures, signing-enabled-and-complete, unsigned RPM metadata, and a deb-only artifact with no out/rpm directory
  • Pre-existing checks confirmed still failing correctly for missing release-info.json and missing per-architecture APT metadata
  • npm test - 129 tests pass

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>
@guanzhousongmicrosoft

Copy link
Copy Markdown
ContributorAuthor

Closing in favor of a PR from my personal account. Same change, reopening shortly.

@guanzhousongmicrosoft
guanzhousongmicrosoft deleted the fix/optional-gpg-signing-and-packaging branch August 4, 2026 02:14
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[IMPROVEMENT] Make GPG signing and packaging optional in CD build

1 participant

@guanzhousongmicrosoft