CI - Continuous Integration

Workflows

ci.yml runs on every pull request (and is also called by cd-staging.yml before a staging deploy). It has four jobs:
- ci-brakeman — Brakeman static security analysis on uala-main
- ci-check-database-schema-sync — checks db/schema.rb is in sync with migrations
- ci-lint — RuboCop, run as a matrix across every Ruby sub-app (connect-integration, store-integration, tw-integration, uala-admin, uala-auth, uala-brands, uala-core, uala-graph, uala-internal-tools, uala-main, uala-statistics)
- ci-tests-coverage — RSpec + Undercover coverage, same matrix, against Postgres/Redis/Kafka/ ClickHouse/OpenSearch service containers
ci-actionlint.yml lints any change under .github/** via the shared ci-actionlint.yml reusable workflow.

Deployment (CD) is a separate set of workflows — see CD - Continuous Deployment, covering both test environments and production releases — built on reusable workflows from treatwell/shared-gh-actions. Application secrets do not travel through either — they are set in AWS Secrets Manager and mounted by the Secrets Store CSI driver, see Deployment secrets flow.

Every job's logs are visible directly in the Actions tab of the run in question — click into the failing job to see the full step-by-step output.

To re-run a failed job (or the whole run): use the "Re-run jobs" button in the GitHub UI, or gh run rerun <run-id> --repo treatwell/uala-backend (add --failed to only re-run failed jobs).
To watch a run from the CLI as it progresses: gh run watch <run-id> --repo treatwell/uala-backend.
Flaky infra failures (service container not healthy in time, transient network error) are usually fixed by a re-run; a failure that reproduces on re-run is almost always a real issue with the change under test.