fix: deploy API and CI — release-based image tags, version endpoint, prod compose #455
Conversation
- Add trailing newline to frontend/.env.production (lint) - Clarify apiClient baseURL comment for sandbox/production - Add Frontend: Lint and Build workflow on develop - Add docs/DEPLOY_RESOLUTION_STEPS.md for PR follow-up
- devbox.json: use kind-config.yaml (file exists as .yaml) - deploy/manifests/balancer/overlays/kind: overlay with secretGenerator for balancer-config (SQLite) so kind runs without PostgreSQL - deploy/kind-test.sh: create cluster, install ingress, build/load image, apply kind overlay, wait for deployment, curl API and verify status
…ath" This reverts commit 1b36e6f.
…, manual deploy - Deploy: Downstream: add permissions (contents, actions, pull-requests), add workflow_dispatch target (both|sandbox|live) for manual deploy; CD to sandbox on develop, live on release; manual run opens PRs to cluster repos - Remove frontend/.env.production and VITE_API_BASE_URL from .env (relative URLs) - SPA catch-all: always register, serve index.html at request time or 404 - Docs: README/CLAUDE/MIGRATION/DEPLOY_RESOLUTION_STEPS and PR body
TineoC
changed the title
TineoC
changed the title
|
This PR depends on the following Pull Requests in the
Please ensure those are merged and Flux is bootstrapped in the cluster before relying on this new workflow. |
themightychris
left a comment
themightychris
left a comment
There was a problem hiding this comment.
Please just open version bump PRs against the desired environment to deploy new versions
VERSION
Outdated
| @@ -0,0 +1 @@ | |||
| 1.2.0 No newline at end of file | |||
There was a problem hiding this comment.
I recommend against tracking any version number in-tree, it creates a lot of annoying chicken-and-egg problems. A better approach is to trigger CI on GitHub release and put the version in the env from the release tag. You can pass in to docker builds via build args if you need the app to be self-aware of its version (e.g. to expose within the UI) and the official docker build action has feature for automatically pulling image tags from release versions
There was a problem hiding this comment.
Hey i'm.sorry, this file was not supposed to be in the pr
When I'm back home I would delete the Version file. If I'm not wrong, the main branch release strategy is not affected by this changes. The only new steps are the dev tag structure so the sandbox cluster pulls the latest timestamp |
TineoC
changed the title
|
@sahilds1 these changes are now ready to be merged into develop. Once that merge is complete, the CI workflow will generate a new image tag (following the vX.Y.Z-dev.TIMESTAMP format). The next step will be to take that specific tag value and update the image reference in the sandbox cluster repo here: https://github.com/CodeForPhilly/cfp-sandbox-cluster/blob/main/balancer/kustomization.yaml#L14 This will verify the new deployment logic in the sandbox environment. |
| DOCKER_TAG="${TAG#v}" | ||
| elif [[ "${{ github.ref }}" == "refs/heads/main" ]]; then | ||
| # Attempt to extract version from merge commit or branch if available | ||
| # release-prepare usually creates branch release/vX.Y.Z or commit "Release vX.Y.Z" |
There was a problem hiding this comment.
release-prepare does not create any branches, only opens a develop -> main PR or updates the changelog comment within it.
I would delete this logic branch for main and remove main from the trigger branches. main should never be getting pushed to outside the develop -> main release PR merges and those generate releases which will trigger runs of this action within the release event context. Unless the develop -> main workflow is being broken, the main push trigger and release trigger would only ever get triggered at the exact same time on the same commit
@TineoC I'm going to leave it to @themightychris to LGTM this PR since he has requested changes to it |
|
Please tag me when it's ready for another look |
3 participants
Fix deploy and CI: release-based image tagging, version-aware app, and prod stack.
CI & container publishing
developandmain.v1.2.0→1.2.0).X.Y.Z-dev.<timestamp>(e.g.1.2.0-dev.20260208120000).Version-aware app
/api/v1/api/versionendpoint (readsVERSIONenv, fallback"dev").Versioncomponent; Footer and About page show app version. API base cleanup (V1_API_BASEto avoid repeating/api/v1/api).Docker & compose
ARG VERSION/ENV VERSIONfor the version endpoint.dbservice and shared network so the app can resolveSQL_HOST=dbwhen running the prod stack locally.Other