Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Correct development target Terraform owner metadata

Open
#459 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
50/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python

Research direction

The mislabeled value is terraform_root for the website-development target in deploy/deployment_targets.py, around line 533, which currently reads main/website and should read main/dev. Leave the production target's main/website root and all target, account, region, secret and image guards unchanged. Find the existing contract tests that cover this metadata and run them; done means the development target reports main/dev, production ownership is untouched, and those tests pass without any cloud, state or secret access.

Written by the indexing model from the issue text.

Description

bug infra needs grooming

Raw intake

During DTC #455 exact-head deployment diagnosis, a read-only source audit found that deploy/deployment_targets.py at fde01ffa3f46e790ec0d05f13f80fd8ddfce6a7c labels the website-development target's terraform_root as main/website (line 533).

Current AWS committed source at 2b9b0102dc19c9925e84862213b7de9f5d19ee4b owns development website resources under main/dev; main/website is the production root. The misleading field also appears in deployment receipts and can confuse recovery root selection.

This is separate from the failed deployment's secret-name-set mismatch. Current DTC and AWS secret-reference declarations agree; the selected live website-dev-web:22 differs. Changing ownership metadata alone does not establish runtime recovery.

Please groom a narrow source metadata correction and its existing contract coverage under the normal independent lifecycle. Preserve target/account/region/secret/image guards, production ownership and all UI/features. No cloud apply, credentials/state/secret-value access, database reset, or deployment retry is authorized by this intake.

Evidence: #455 on-call receipt https://github.com/DataTalksClub/website/issues/455#issuecomment-6085255922 and AWS #58 recovery handoff https://github.com/DataTalksClub/aws-infra/issues/58#issuecomment-6085435261 .

Dominant language
Python
Stars
0
Forks
0
PR merge metrics
No merged PRs in 30d

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DataTalksClub/website

All issues in DataTalksClub/website

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.