Merged
Conversation
## Summary
Pre-NLB chore release bundling deferred maintenance items that carry zero customer-facing risk individually and benefit from shipping together.
- **G1 CronFunction:** Migrate inline Lambda from nodejs16.x/AWS SDK v2 to nodejs22.x/AWS SDK v3 (nodejs16.x is EOL; nodejs18+ does not bundle SDK v2)
- **Fargate region map:** Enable Fargate in ap-northeast-1, ca-central-1, us-west-1 (supported since 2018-2019, flags were stale)
- **GitHub Actions:** Bump checkout@v4, setup-go@v4 with go-version-file, set-output deprecation fix, qemu@v3, buildx@v3
- **kubectl:** Bump v1.13.0 to v1.28.15 in Dockerfile, Dockerfile.arm, ci/dependencies.sh (debug-only binary, not in operational path)
## Details
### G1 CronFunction (provider/aws/formation/g1/app.json.tmpl)
Runtime and SDK must change together -- nodejs18+ does not ship `aws-sdk` v2. The rewrite preserves exact functional behavior:
| Aspect | Before | After |
|--------|--------|-------|
| Runtime | nodejs16.x | nodejs22.x |
| ECS client | `new aws.ECS({maxRetries:10})` | `new ECSClient({maxAttempts:11})` |
| CW Logs client | `new aws.CloudWatchLogs()` | `new CloudWatchLogsClient({})` |
| Handler | callback-based (`cb`) | async/await |
| Skew delay | `setTimeout(fn, skew)` | `await new Promise(r => setTimeout(r, skew))` |
- Only affects Generation 1 apps, only on next CF update (deploy/scale/param change)
- Failure mode: cron tasks don't fire (not rack-down, not resource destruction)
- Lambda ARN preserved; EventBridge rules and CronRole IAM unchanged
### Fargate region map (provider/aws/formation/rack.json)
Pure metadata update. The `Fargate` mapping value feeds into a Docker label and a CF Output, but `p.Fargate` is set-but-never-read in Go code. No CF Conditions gate on this value. Service-level Fargate still requires explicit `Fargate=Yes` in convox.yml.
### GitHub Actions (.github/workflows/release.yml, publish.yml)
CI-only changes. Node 16 action runners are deprecated by GitHub. `go-version-file: go.mod` pins Go version deterministically (previously relied on runner default).
### kubectl (Dockerfile, Dockerfile.arm, ci/dependencies.sh)
kubectl is installed in the rack image for debugging only -- not called from any Go code. v1.13.0 is from December 2018. Docker CLI versions intentionally not changed (requires AMI coordination).
## Not changed
- Docker CLI versions in Dockerfiles
- AWS SDK Go version
- Any Go source code
- service.json.tmpl or app.json.tmpl (Gen 2)
- Resource templates (postgres, redis, valkey, etc.)
## Summary
- Add `Version` parameter reference to `BuildLaunchTemplate` UserData to guarantee a new LaunchTemplate version is created on every rack update
- Eliminates a race condition where the rack API receives new TLS certificates before the build instance is replaced, causing a `tls: unknown certificate authority` error window during updates
## Background
During a rack version update, self-signed Docker TLS certificates are regenerated by a CloudFormation custom resource Lambda. The rack API ECS tasks restart with the new certificates quickly, but the build EC2 instance replacement depends on CloudFormation detecting a change in the `BuildLaunchTemplate` UserData (via custom resource output propagation). If that propagation chain doesn't produce a detectable change, the ASG rolling update is not triggered, leaving the build instance running with stale certificates.
Even when the rolling update IS triggered, the API tasks can restart with new certificates before the build instance replacement completes, creating a failure window where builds fail with:
```
remote error: tls: unknown certificate authority
```
## Change
One line added to `BuildLaunchTemplate` UserData in `provider/aws/formation/rack.json`:
```json
"# rack-version: ", { "Ref": "Version" }, "\n",
```
This is a cloud-config comment with no effect on instance boot behavior. Because `{ "Ref": "Version" }` resolves to a different value on every rack version update, the UserData content always changes, which forces a new LaunchTemplate version, which triggers the `AutoScalingRollingUpdate` policy on the `BuildInstances` ASG.
### What is the feature/fix? Fix TestBuildExport failure caused by Docker CLI version mismatch in test mocks ### Does it has a breaking change? no ### How to use/test it? Run CI
nightfury1204
approved these changes
Mar 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Requests
Milestone Release