Add a script to copy Render's env into GCP by bishopBethel · Pull Request #263 · devasignhq/agent

bishopBethel · 2026-09-24T14:44:41Z

Reads the service's variables from the Render API (or a local env file), writes known secrets to Secret Manager via gcloud stdin with accessor granted to the devasign-api service account, and writes the rest to a gitignored Cloud Run env-vars YAML. Values are never printed or put on argv; without --apply it only previews the classification.

deploy/ is excluded from the image.

Reads the service's variables from the Render API (or a local env file), writes known secrets to Secret Manager via gcloud stdin with accessor granted to the devasign-api service account, and writes the rest to a gitignored Cloud Run env-vars YAML. Values are never printed or put on argv; without --apply it only previews the classification. deploy/ is excluded from the image. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

vercel · 2026-09-24T14:44:47Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
contributor	Ready	Preview	Sep 24, 2026 4:56pm UTC
sponsor	Ready	Preview	Sep 24, 2026 4:56pm UTC

devasign-agent

DevAsign Code Review

📋 Criteria not met (1) · 🐞 Bugs (2) · 📝 Nitpicks (2) · ❌ Tests failing (1)

🟡 Merge score: 59/100

7 of 8 acceptance criteria met, 1 not met.
The script implements the intended Render-to-GCP import flow and most criteria are satisfied by concrete code: env sourced from Render API or file, secret classification into Secret Manager via stdin, accessor grant to devasign-api, plain vars to a YAML, no value printing, preview-only without --app

⚠️ 1 of 6 verified tests are failing — check the "Tests by DevAsign" comment before merging.

Prompt to fix all issues

You are helping fix PR "Add a script to copy Render's env into GCP" in devasignhq/agent. Automated review surfaced the items below — failed acceptance criteria and review findings. Each item states what was required, what's wrong with the current diff, and how to fix it; the embedded fix blocks include the expected behavior and the relevant diff hunk. Apply each fix so the item is resolved. Items tagged **Blocker** gate approval; the rest are advisory but worth addressing. Don't introduce changes beyond what's listed.

## End goal
A script migrates a Render service's environment variables into GCP, storing known secrets in Secret Manager and remaining variables in a Cloud Run env-vars YAML, without exposing values.

## Failed acceptance criteria

### 1. Required: Variables not classified as secrets are written to a Cloud Run env-vars YAML file that is gitignored. (5)
What's wrong now: Non-secret vars are written to envYamlPath (`.env.cloudrun.yaml`) under --apply, satisfying the 'written to YAML' half. But the 'gitignored' requirement is not met by this diff: the only ignore change is `deploy` added to backend/.dockerignore (line 15), which excludes it from the Docker image, not from git. No .gitignore entry for `.env.cloudrun.yaml` (or `backend/deploy/`) is added in the diff, so the plaintext env YAML would be committable. The PR/comment claim that it is gitignored is unverified against the diff. If a pre-existing .gitignore already covers deploy/ it is not shown; but since the file lives in a newly-created directory, a positive ignore entry should be added.

How to fix:
**Suggested change** (`backend/deploy/gcp/import-render-env.mjs:56`):

```diff
-const envYamlPath = path.join(outDir, ".env.cloudrun.yaml");
+const envYamlPath = path.join(outDir, ".env.cloudrun.yaml"); // ensure backend/.gitignore ignores deploy/gcp/.env.cloudrun.yaml
```

Fix: Gitignore the generated Cloud Run env-vars files

File: backend/.gitignore (or backend/deploy/gcp/.gitignore)
Symbol: n/a

Issue:
The script writes `.env.cloudrun.yaml` (plaintext non-secret env values) and `.env.cloudrun.secrets` into backend/deploy/gcp/. The PR claims this YAML is gitignored, but the diff only adds `deploy` to backend/.dockerignore, which excludes it from the Docker image, not from git. Nothing prevents the plaintext env file from being committed.

Expected behavior:
The generated env YAML and secrets-spec files are ignored by git so they can never be committed.

Suggested approach:
Add a .gitignore (or append to backend/.gitignore) entries: `deploy/gcp/.env.cloudrun.yaml` and `deploy/gcp/.env.cloudrun.secrets` (or simply `deploy/gcp/.env.cloudrun.*`). Confirm no existing .gitignore already covers it before adding.

Relevant diff:
```diff
+writeFileSync(envYamlPath, plain.map((k) => `${k}: ${JSON.stringify(vars.get(k))}\n`).join(""), { mode: 0o600 });
+writeFileSync(secretsSpecPath, secrets.map((k) => `${k}=${k}:latest`).join(",") + "\n");
```

## Review findings

### 1. [Bug · Warn] `backend/deploy/gcp/import-render-env.mjs` — The Render env-vars endpoint returns a paginated response where each element is an object like `{ envVar: {...}, cursor: "..." }`. The code iterates `for (const { envVar } of page)` and also reads `page.length` and `page[page.length - 1].cursor`, which requires `page` to be an array. If the API returns a wrapped object (e.g. `{ items: [...] }`) or the destructuring assumptions are wrong, the iteration silently produces nothing or throws. Given the code assumes `page` is a bare array with `.cursor` on each element, a mismatch with the actual response shape breaks the import.

Fix: Verify Render env-vars response shape before destructuring

File: backend/deploy/gcp/import-render-env.mjs
Symbol: fromRender

Issue:
The code assumes the Render API returns a top-level array where each element has `envVar` and `cursor`. If the response is wrapped or the pagination shape differs, iteration throws or yields nothing.

Expected behavior:
The function should correctly read the array of env-var entries regardless of whether it is nested, and stop pagination on the true last page.

Suggested approach:
Confirm the actual JSON shape from the Render API docs; if entries are nested under a key, extract that array before iterating. Guard against a non-array response.

Relevant diff:
```diff
+    const page = await res.json();
+    for (const { envVar } of page) vars.set(envVar.key, envVar.value ?? "");
+    if (page.length < 100) return vars;
+    cursor = encodeURIComponent(page[page.length - 1].cursor);
```

### 2. [Bug · Warn] `backend/deploy/gcp/import-render-env.mjs` — In apply mode, secrets are written to Secret Manager first (line 139), and only afterwards is the YAML/secrets-spec written (lines 141-142). If `putSecret` throws for any key (e.g. a gcloud grant failure), the loop aborts with some secrets already written to Secret Manager but no env YAML or secrets spec file produced, leaving GCP state partially populated and no local record of what was applied.

Fix: Make apply-mode writes resilient to partial failure

File: backend/deploy/gcp/import-render-env.mjs
Symbol: (top-level apply block)

Issue:
If putSecret throws mid-loop, some secrets are already written to Secret Manager but the local YAML/secrets-spec files are never produced, leaving inconsistent state. Re-running adds further secret versions non-idempotently.

Expected behavior:
A failure partway through should leave a clear record of what was applied, or wrap the loop so the spec files still reflect completed work.

Suggested approach:
Wrap the secret loop in try/finally so the spec/YAML files are written for successfully applied keys, or collect results and report which secrets were applied before rethrowing.

Relevant diff:
```diff
+const member = `serviceAccount:${args["service-account"]}@${args.project}.iam.gserviceaccount.com`;
+for (const key of secrets) console.log(`  ${key}: ${putSecret(key, vars.get(key), member)}`);
+
+writeFileSync(envYamlPath, plain.map((k) => `${k}: ${JSON.stringify(vars.get(k))}\n`).join(""), { mode: 0o600 });
```

### 3. [Convention · Nit] `backend/deploy/gcp/import-render-env.mjs` — The backend rule 'Always read, always write tests for all the changes made.' The diff adds a new 144-line backend script (import-render-env.mjs) with parsing/filtering logic (fromFile, SKIP, classification) but includes no accompanying tests.

Fix: Add tests for the new Render env import script

File: backend/deploy/gcp/import-render-env.mjs
Symbol: fromFile / SKIP / classification loop

Issue:
The repo DEVASIGN.md backend rule states 'Always read, always write tests for all the changes made.' This PR adds a new backend script with pure, testable logic (env-file parsing in fromFile, the SKIP predicate, and secret/plain/skip classification) but ships no tests.

Expected behavior:
The testable pure functions should have unit tests covering parsing edge cases (quoted values, export prefix), SKIP matching, and secret vs plain classification.

Suggested approach:
Refactor fromFile and the classification logic into exported helpers and add a test file exercising them; keep the CLI entrypoint side-effect-guarded so importing for tests does not run gcloud.

Relevant diff:
```diff
+function fromFile(file) {
+  const vars = new Map();
+  for (const line of readFileSync(file, "utf8").split(/\r?\n/)) {
+    const m = line.match(/^\s*(?:export\s+)?([A-Za-z_][A-Za-z0-9_]*)\s*=\s*(.*)$/);
+    if (!m) continue;
+    let value = m[2].trim();
+    if (/^(["']).*\1$/.test(value)) value = value.slice(1, -1);
+    vars.set(m[1], value);
+  }
+  return vars;
+}
```

## Your task
Work through every item above — the failed acceptance criteria and each review finding. For each one: understand the gap from "What's wrong now", implement the change so the Required behavior holds (each fix block's `Expected behavior` describes the target state), and use the `Relevant diff` hunks as the anchor for where to edit. After each change, re-verify it resolves the item. Treat **Blocker**-tagged items as required (they block approval); address the rest too.

devasign-agent · 2026-09-24T14:47:33Z

Tests by DevAsign

✅ Passed (5) · ❌ Failed (1) · ⚠️ Unverifiable (2)

5 of 8 criteria verified by tests, 1 failed, 2 unverifiable. Each verdict below links to its evidence.

1 — The script sources the service's environment variables either from the Render API or from a local env file. (pass)

Verdict: pass

Both subtests pass: sources env vars from a local env file via --from-file and from the Render API via --render-service.

Test: .devasign/tests/import-render-env-sources.test.mjs · integration

Conversation

bishopBethel commented Sep 24, 2026

Uh oh!

vercel Bot commented Sep 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

devasign-agent Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

DevAsign Code Review

🟡 Merge score: 59/100

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

devasign-agent Bot commented Sep 24, 2026

Tests by DevAsign

Uh oh!

devasign-agent Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

DevAsign Code Review

🟡 Merge score: 67/100

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

devasign-agent Bot commented Sep 24, 2026

Tests by DevAsign

Uh oh!

devasign-agent Bot left a comment

Choose a reason for hiding this comment

DevAsign Code Review

✅ Merge score: 81/100

Uh oh!

Uh oh!

devasign-agent Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

DevAsign Code Review

✅ Merge score: 100/100

Uh oh!

devasign-agent Bot commented Sep 24, 2026

Tests by DevAsign

Uh oh!

Uh oh!

devasign-agent Bot commented Sep 24, 2026

Tests by DevAsign

Uh oh!

This branch was successfully deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

vercel Bot commented Sep 24, 2026 •

edited

Loading

devasign-agent Bot left a comment •

edited

Loading

devasign-agent Bot left a comment •

edited

Loading

devasign-agent Bot left a comment •

edited

Loading