dhess
commented
1 year ago The way the frontend deployments currently work is this:
- On a merge to
main, our Cloudflare GitHub workflow is triggered, and this pushes the frontend build frommainto a unique URL, something like https://600eb0d0.primer-app.pages.dev. - Then Cloudflare sees that this is the new
mainon this PR and updates the "Production" URL, https://primer-app.pages.dev, to point to the unique URL as a CNAME (or Cloudflare equivalent).
If we could disable the automatic CNAME update somehow, and instead defer that update to some action taken by Argo CD when we "deploy" a frontend+backend release to the hackworth-code-gitops repo, then that would do the trick. However, I don't know offhand how to disable that. Perhaps it's an option to the Cloudflare Pages Action.
As of https://github.com/hackworthltd/primer-app/commit/5f00d8fb49b911407614950908638b9a1b2382a5, our deployment situation is not ideal:
primer-servicecontainer when PRs in this repo are merged tomain. This is because, per best "gitops" practices, we want to separate code repos from configuration/deployment repos. The backend deployment configuration is now maintained in ourhackworth-code-gitopsrepo.main. This is because the deployment of the frontend code is trivial withcloudflare/pages-action, but not as straightforward with our new gitops deployment system, Argo CD.This means that the frontend and backend must be manually sync'ed up when we bump the Primer pin, which is obviously not great. I'll need to think about how to syncrhonize these two altogether different deployment mechanisms.
One short-term fix would be to temporarily move the
hackworth-code-gitopsdeployment bits for the backend into this repo, so that merges tomainwould a) push the frontend to Cloudflare Pages, and b) cause Argo CD to deploy the pinnedprimer-servicecontainer.Unless I can think of something better (and implement it) in the next or two, I think I'll fall back to this short-term fix.