Skip to content

ci: deploy main through the reqsai-infra MVP pipeline - #46

Merged
jhosepmyr merged 1 commit into
developfrom
ci/deploy-via-infra
Oct 7, 2026
Merged

jhosepmyr merged 1 commit into
developfrom
ci/deploy-via-infra

Conversation

@jhosepmyr

Copy link
Copy Markdown
Contributor

Description

Replaces the obsolete deploy.yml. It built the app, synced it to an S3 bucket and invalidated a CloudFront distribution, but that AWS stack (bucket, distribution, GitHub OIDC provider and github-actions-web role) no longer exists, so the workflow would fail on the next push to main.

Production now runs on a single EC2 instance (https://reqsai.tech), where the frontend is the nginx image from this repo's Dockerfile. The deploy pipeline lives in Kntro-Soft/reqsai-infra (.github/workflows/deploy-mvp.yml, see Kntro-Soft/reqsai-infra#7). This workflow only triggers it:

  • On push to main (or a manual run from main), it runs gh workflow run deploy-mvp.yml --repo Kntro-Soft/reqsai-infra --ref main -f web_ref=<pushed SHA>. The infra workflow builds the linux/arm64 image from that exact commit on a free arm64 runner, uploads it to the instance over SSH tunnelled through SSM, recreates the container and checks the public health endpoint. api_ref keeps its default, main.
  • It authenticates with a new repository secret, INFRA_DEPLOY_TOKEN. If the secret is missing, the job logs a notice and succeeds, so main never goes red because of the deploy.
  • Manual runs from any branch other than main are skipped. To deploy a branch, run the infra workflow with web_ref=<branch>.

Cache headers: nginx.conf inside the image already serves index.html with no-cache and hashed assets as immutable, as the S3 upload did. One gap carried over from the image (not introduced here): i18n/*.json gets no explicit Cache-Control from nginx, while the S3 upload set no-cache,must-revalidate, so browsers may keep old translations for a while after a deploy. Worth a small follow-up in nginx.conf.

Feature module / area: ci

Related issue / US: —


Type of Change

  • feat — new feature or UI component
  • fix — bug fix
  • refactor — code change without behavior change
  • test — tests only
  • docs — documentation only
  • build / ci — build, dependencies, or CI/CD
  • chore — maintenance

Checklist

  • The PR targets develop (not main)
  • Branch name follows feature/*, bugfix/*, or hotfix/*: the branch is ci/deploy-via-infra, matching the ci type of the change.
  • Commits follow Conventional Commits (checked by the commitlint hook)
  • bun run lint passes locally (ESLint + angular-eslint): not applicable, no TypeScript changes.
  • bun run test passes locally (Vitest): not applicable.
  • bun run build passes locally (no type errors, no budget exceeded): not applicable here; the infra pipeline built this repo's image from feature/mvp-ux-polish in its validation run.
  • New components use ChangeDetectionStrategy.OnPush and Angular signals: not applicable.
  • No localStorage/sessionStorage access for JWT tokens (use the auth store): not applicable.
  • No bypassSecurityTrust* calls without explicit review: not applicable.
  • No secrets, credentials, or .env content committed
  • CHANGELOG.md updated under [Unreleased]

How to Test

  1. Without INFRA_DEPLOY_TOKEN: after merge, any push to main shows a green Deploy run with the notice "Deploy not triggered".
  2. With the token: a push to main creates a Deploy MVP run in https://github.com/Kntro-Soft/reqsai-infra/actions/workflows/deploy-mvp.yml with web_ref set to the pushed SHA. The run summary shows the ref and the commit of each image.

Screenshots / recordings (if UI changes)

None, no UI changes.

Notes (optional)

Creating INFRA_DEPLOY_TOKEN (one-time, an org member with admin on reqsai-infra)

GITHUB_TOKEN cannot start workflows in another repository, so the dispatch needs its own token:

  1. If the organization blocks fine-grained tokens or requires approval: Kntro-Soft → Settings → Personal access tokens → Settings, allow fine-grained tokens (an owner approves the request if approval is on).
  2. Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token.
  3. Resource owner: Kntro-Soft. Expiration: the shortest you are willing to rotate (for example 90 days).
  4. Repository access: Only select repositories → Kntro-Soft/reqsai-infra.
  5. Repository permissions: Actions: Read and write (GitHub adds Metadata: Read-only). Nothing else.
  6. Store it in both app repos; gh prompts for the value without echoing it:
    gh secret set INFRA_DEPLOY_TOKEN -R Kntro-Soft/reqsai-api
    gh secret set INFRA_DEPLOY_TOKEN -R Kntro-Soft/reqsai-web

The token can only start or cancel workflows in reqsai-infra. The AWS role, the SSH key and the vault stay in the infra repo's mvp environment, which only its main branch can use.

Order

Create the token only once main of both reqsai-api and reqsai-web holds the code that should run in production. A push to main here deploys reqsai-api's main too, so a stale main on the other repo would roll it back. The infra workflow must also be on reqsai-infra main (merge Kntro-Soft/reqsai-infra#7 first).

…nd CloudFront

The S3 bucket and CloudFront distribution the old workflow targeted no
longer exist. A push to main now dispatches deploy-mvp.yml in
Kntro-Soft/reqsai-infra with web_ref set to the pushed commit, using the
INFRA_DEPLOY_TOKEN secret; without the secret the job only logs a notice.
@jhosepmyr
jhosepmyr merged commit dc09f0e into develop Oct 7, 2026
5 checks passed
@jhosepmyr

Copy link
Copy Markdown
Contributor Author

Follow-up commit: the deploy trigger now passes api_ref=keep, so a push to this repo's main redeploys only the web and leaves the running API image untouched (before, it defaulted the API to main). INFRA_DEPLOY_TOKEN is now configured as a repo secret.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant