Reconcile develop with master (post-tier promotion + CD strip)#87
Closed
topherwhite wants to merge 4 commits into
Closed
Reconcile develop with master (post-tier promotion + CD strip)#87topherwhite wants to merge 4 commits into
topherwhite wants to merge 4 commits into
Conversation
Mirrors AWS deploy; reuses rfcx/cicd/.github/workflows/rfcx-local-cd.yaml@master. See rfcx/rfcx-api commit fc1b78ff for the pattern + initial rollout proof.
The kops production cluster has been declared dead by the operator (2026-05-18 18:55 EDT). The AWS-targeted `build:` (ECR push) and `deploy:` (kubectl against KUBE_CONFIG_SUPER) jobs have been failing-or-soon-to-fail since, and rfcx-local has been the authoritative production deploy target. This commit: - Drops the `build:` job (uses `rfcx/cicd/ecr-build-push.yaml`) - Drops the `deploy:` job (uses `rfcx/cicd/k8s-deploy.yaml`) - Updates `notify.needs` to depend only on `deploy-rfcx-local` - Updates notify status/footer to surface the rfcx-local result `deploy-rfcx-local` is unchanged: it does its own in-cluster arm64 build via the self-hosted runner in the `cicd` namespace, pushes to the in-cluster registry at 192.168.5.1:30500, and rolls `apps-prod` Deployments via the runner's RBAC. It has no dependency on the AWS `build:`/`deploy:` jobs. `prepare:` and `configure:` are kept (still needed for the branch-name gate on `deploy-rfcx-local` and for notify metadata). `staging` is left in the on.push.branches trigger; with AWS gone it's a no-op on staging push (deploy-rfcx-local gates on namespace==production), which preserves the staging-promotion-PR workflow. See https://github.com/evity-squibbon/rfcx-local STATE.md "AWS / kops decommission status" block for context.
ci(cd): remove AWS build+deploy jobs (kops decommissioned)
Promote staging -> master (AWS CD-strip + feat PRs)
Member
Author
|
Routine reconciliation: brings This PR is BLOCKED until an org member with develop branch-protection approval rights approves. CC operator. |
Member
Author
|
Closing to avoid the delete_branch_on_merge trap (auto-deletes master). Reopening with a topic branch as head instead. |
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.
Summary
Reconciles
developwith the recentmasterstate. The two branches have drifted apart for ~weeks because recent PRs wentfeat → staging → master(orfeat → masterdirectly) and never backflowed intodevelop. Tonight's CD-strip + tier-system + feat work compounded the drift.Why this PR exists
The cd.yaml in this repo says the deploy chain is
develop → staging → master, but the actual chain in practice has beenfeat → staging → master. As a result,developis silently behind and any future merge fromdevelopwould either revert production state or hit conflict-resolution overhead.A
master → developreconciliation merge brings the branches back in line without losing anyone's in-flight feature work (no force-push, no rebase). After this lands, anyone branching offdevelopfor new work starts from current production state.What changes
Merges
masterintodevelop. Result:develop's history includes allmastercommits, plus a merge commit.If there are local
develop-only commits (PRs not yet merged to master), they're preserved by the merge. After this lands,developmay need a CI build to validate the union compiles cleanly.Risks
develophas work-in-progress commits that conflict with master's recent changes. Conflicts resolved per the usual convention (preserve newer behaviour from master where features overlap, preserve develop's WIP otherwise).After this lands
Recommend establishing a convention: open a
master → developreconciliation PR after everystaging → masterpromotion, OR changecd.yamlto dropdevelopfrom the documented chain. Choosing one keeps the branches honest.