docs(guide): name the project flag as load-bearing for build checks - #10484
Open
MarkusNeusinger wants to merge 2 commits into
Open
docs(guide): name the project flag as load-bearing for build checks#10484MarkusNeusinger wants to merge 2 commits into
MarkusNeusinger wants to merge 2 commits into
Conversation
The deploy-check recipe warned about --region but treated --project as incidental. It is not: a gcloud default pointing at another project returns that project's builds, and when its triggers share the names and region, the wrong list is indistinguishable from the right one. Adds the context check that settles it.
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the deployment runbook to treat --project as a required, “load-bearing” flag (alongside --region) when checking Cloud Build deploy history, and records the change in the project changelog so the operational pitfall is discoverable later.
Changes:
- Updates the deploy-check instructions to always pass both
--regionand--project. - Adds a quick context verification step (
gcloud config get-value project) and explains why the failure mode is silent/credible. - Adds a
[Unreleased]changelog entry describing the operational footgun and the documentation fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| CHANGELOG.md | Adds an [Unreleased] Fixed entry documenting the deploy-check pitfall and the runbook update. |
| agentic/docs/project-guide.md | Updates the “Checking whether something actually deployed” runbook to require --project and adds a context check/explanation. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| different one returns *that* project's builds, and when its triggers happen to carry | ||
| the same names in the same region, the wrong answer is indistinguishable from the | ||
| right one — no error, just a credible list of `deploy-api` runs that stop a few days | ||
| ago. It produced a false "nothing has deployed since the 16th" on a day with a dozen |
Comment on lines
+28
to
+29
| deploys. `agentic/docs/project-guide.md` now names both flags and the context check | ||
| that settles it. |
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.
What
The deploy-check runbook in
agentic/docs/project-guide.mdwarned about--regionand treated--projectas incidental. It is not.Why
A gcloud install whose default project is another of the owner's projects returns that project's builds. When those triggers carry the same names (
deploy-api,deploy-app) in the same region (europe-west4), the wrong list is indistinguishable from the right one — no error, no warning, just a credible history of deploys that happens to stop a few days ago.That is not hypothetical. While preparing the v3.1.0 release I ran the check without the flag and concluded "no builds since 2026-08-16" on a day anyplot had in fact deployed twelve times. The real history was one flag away.
Change
--regiongcloud config get-value projectmust printanyplotDocs-only; no code paths touched.