Commit Graph

4 Commits (0113509fa17c49f93550c655d941aea859b2ad69)

Author SHA1 Message Date
Talha Ahmed 0113509fa1 Deploy: stop shipping 90 MB of node_modules the build throws away
CI / checks (push) Successful in 2m46s Details
The S3 artifact is 32.9 MiB compressed. Every other project's zip in that
bucket is under 1 MiB. The difference is frontend/node_modules, which is
committed to this repo and so was swept into every upload.

Earlier I left it in because nothing in the repo says what consumes the
bucket object, and if that side ran the app without installing dependencies,
dropping it would have broken the deploy. That is now answered rather than
assumed. Traced on the instance:

  CodeDeploy extracts to /opt/codedeploy-extracted-5, the AfterInstall hook
  copies the tree to /home/ec2-user/utopia-ai-hr-ats-portal-deployment-group,
  then runs `docker compose --env-file ./backend/.env up -d --build`.

Eleven containers come up and the only Node one is hrms-frontend, built from
frontend/Dockerfile, which does `npm ci` against the lockfile. On top of that
frontend/.dockerignore excludes node_modules/ from the build context outright,
so even the copy that arrived could not have been read. It was carried across
the wire on every merge to main and then discarded unread.

The exclusion patterns were verified rather than trusted: zip -r with
-x on a synthetic tree in a temp dir on the box, since zip is not available
locally. That run also confirmed the previous commit's other fix — the
original `-x ".gitignore/*"` really did fail to match the file, and
`-x ".gitignore"` matches it.

Not done here, deliberately: node_modules is still tracked in git, which is
why it was in the artifact in the first place. Untracking it deletes 5,230
files from every other contributor's working tree on their next pull, across
thirteen active branches, and needs a heads-up rather than a surprise.

Two things found while reading the deploy script, neither touched:

  - It copies with `cp -r` and never deletes, so a file removed from the repo
    survives on the server indefinitely. Switching to a delete-on-sync would
    risk backend/.env, which the script deliberately preserves.
  - It re-downloads the latest docker compose and buildx from GitHub on every
    single deploy, unpinned, as root.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 18:39:43 +05:00
Talha Ahmed 3b5ba425e8 CI: verify the build before it ships, and fix two dead lines in the deploy
CI / checks (push) Successful in 3m36s Details
The pipeline deployed whatever was on main without checking any of it. No
build, no tests, no lint. A frontend that failed to compile zipped and
uploaded exactly like a working one, and the first sign of trouble would have
been the running site.

The checks now gate the deploy. `deploy` needs a `checks` job, so a red main
never reaches the bucket. A second workflow runs the same script on branches
and pull requests, so the answer arrives before the merge rather than after
it. main is excluded there because the deploy workflow already covers it.

Both call scripts/ci-checks.sh rather than inlining the commands twice, which
is the only way the two cannot drift into disagreeing about what passing means.

What gates, and what deliberately does not:

  - frontend: npm ci then npm run verify. All four suites are jsdom, so no
    browser is needed on the runner. Node 22 matches frontend/Dockerfile.
  - bulk-ats: ruff check, ruff format --check, mypy, pytest. Scoped to app and
    tests. Repo-wide, ruff reports 926 errors and would reformat 126 files —
    the backend is written to another style and demanding a rewrite of it is
    not this change's business. The scoped set is clean today.
  - backend/tests: passes and gates, minus test_candidate_forms.py and
    test_employment_agent.py. Those nine failures predate this change and are
    unrelated to it. They are named in the script, not silently skipped, so
    the exclusion stays visible and someone can delete the two lines.

Two dead lines in the deploy, found while reading it:

  - The step named "Configure AWS credentials" set three variables and then
    only echoed a message. `env:` is scoped to its own step, so the values were
    discarded before anything could use them. It did nothing while reading as
    though credentials were configured globally. Removed; the upload step sets
    them where they are actually used.
  - `-x ".gitignore/*"` excludes a *directory* named .gitignore, which does not
    exist, so the file was never excluded. Now `-x ".gitignore"`.

The zip still ships frontend/node_modules, about 90 MB and most of the
artifact. Left alone on purpose: nothing in this repo says what unpacks the
object — there is no appspec and no deploy script here — so if that side runs
without installing dependencies, dropping it would break the deploy. The
workflow now carries a comment saying so and the one-line change to make once
that is confirmed.

.gitattributes pins *.sh to LF. The script is bash on a Linux runner; committed
with CRLF from a machine with core.autocrlf=false it would fail on line one
with `$'\r': command not found`, which reads as a broken pipeline rather than a
line-ending problem.

Verified by running scripts/ci-checks.sh locally end to end, exit 0. Only the
npm ci line was skipped, because it would rewrite the 5,230 committed
node_modules files; frontend/Dockerfile already builds that way. Both workflow
files were parsed and their job graph inspected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 18:22:59 +05:00
yaseen.zafar 32af1a3d37 added workflow fix
Deploy to S3 / deploy (push) Successful in 32s Details
2026-08-19 17:00:15 +05:00
yaseen.zafar 79055d01c1 added gitea workflow config
Deploy to S3 / deploy (push) Successful in 31s Details
2026-08-19 15:31:01 +05:00