Conversation
The workflow pushed the changed dashboards to the staging Grafana only. It now pushes them to the production Grafana also. - The workflow applies the preview to both environments in one job. The job posts one sticky comment. The comment shows each changed dashboard one time, with one link for each environment. - The workflow applies staging first. The comment step runs also when an apply step fails. If production fails, the comment keeps the staging links and shows a warning. - The new script scripts/ci-apply-preview.sh holds the steps for one environment. Staging and production run the same code. - Each Grafana token stays in its own step. The workflow writes no token to $GITHUB_ENV. - The cleanup job deletes the preview from both environments when the PR closes. - The daily sweep workflow sweeps both environments. The production IAM role trusts repo:cardstack/boxel:* with no ref condition. The role grants the three SSM parameters that the preview reads. This change needs no infrastructure work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a57d7b1649
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
A code review found that the previous design gave production credentials to pull-request-controlled code. GitHub loads a `pull_request` workflow, and every script that workflow calls, from the pull request itself. A contributor could therefore change those files and read the temporary production AWS credentials, the decrypted production grafanactl token, and GRAFANA_SECRET. GitHub always loads a `workflow_run` workflow from the default branch. The production preview moves there: - observability-preview.yml keeps staging credentials only. - observability-preview-production.yml applies the production preview, and removes it when the pull request closes. It restores every script from the default branch, then overlays only packages/observability/grafanactl/resources from the pull request. Those manifests are data, and no step runs them. - render-preview.sh fails now if a manifest that it emits lacks the `pr<n>-` prefix. A crafted manifest cannot address a canonical dashboard. - The production workflow asserts the production server URL before it reads a credential. - The production sweep refuses a ref other than main. The staging workflow posts a comment for staging. The production workflow rewrites that comment with one link for each environment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
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
1 participant
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 this changes
The PR preview pushed the changed dashboards to the staging Grafana only. It now pushes them to the production Grafana also.
The PR gets one sticky comment, not one comment for each environment. The comment shows each changed dashboard one time, with one link for each environment:
Why there are two workflows
The first revision of this PR ran the production push from the
pull_requestworkflow. A review found that this hands production credentials to code the pull request controls. GitHub loads apull_requestworkflow, and every script that workflow calls, from the pull request itself. A contributor could change those files and read the temporary AWS credentials, the decrypted production grafanactl token, andGRAFANA_SECRET. The same path also defeats the main-only guard inobservability-apply-production.yml.No guard inside the
pull_requestworkflow fixes this, because the pull request can edit the guard.GitHub always loads a
workflow_runworkflow from the default branch. The production preview therefore lives in its own workflow:observability-preview.ymlpull_requestobservability-preview-production.ymlworkflow_runThe trust boundary is the "Overlay" step. The production job checks out the default branch, installs
grafanactlwhile only default-branch code is on disk, then checks out the pull request and restores.githubandpackages/observabilityfrom the default branch. It takes back onlypackages/observability/grafanactl/resources. Those manifests are the single pull-request input, they are data, and no step runs them.Three further controls:
render-preview.shfails if a manifest it emits lacks thepr<n>-prefix, so a crafted manifest cannot address a canonical dashboard.config.yamlbefore it reads any credential.main.How the comment stays single
observability-preview.ymlposts a comment for staging.observability-preview-production.ymlrewrites that same comment with a link for each environment. If the production job fails, the staging-only comment stands. If the staging run failed, the comment lists production and shows a warning.Tests
actionlintandprettier --checkpass on all three workflows.shellcheckpasses on every observability script.github,contextandcoreobjects, over five conditions: staging only, both environments, staging failed, no dashboard changed, and one dashboard.render-preview.shagainst a real two-dashboard change. It producedpr999-UIDs for both dashboards and the folder.prefix_uidand ran it again. The new assertion failed the render with exit 1, so the check is not vacuous.Note for the reviewer
The production preview substitutes the real
GRAFANA_SECRET, so operator buttons on a preview dashboard act on production. Tell me if you prefer a dummy value there.This branch is 556 commits behind
main. I have not mergedmainin, because the merge touches files that carry uncommitted local work.🤖 Generated with Claude Code