Remove build.binary. It can be a two liner Dockerfile if absolutely necessary #330
Labels
No labels
Compat/Breaking
Component/Enclave-Builder
Component/Infrastructure
Deploy/BYOC
Deploy/Full-managed
Deploy/Self-hosted
Interface/API
Interface/CLI
Interface/Git
Interface/Web
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority/Critical
Priority/High
Priority/Low
Priority/Medium
Reviewed/Confirmed
Reviewed/Duplicate
Reviewed/Invalid
Reviewed/Won't Fix
Status/Abandoned
Status/Blocked
Status/Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
public/platform#330
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
keeps introducing complexity. It's only useful for statically linked programs, and I doubt enough people are going to want it to require using it. If they really want, they can do the following in a Containerfile:
PR #263 made
build.binaryoptional for local app builds, which partially reduced the complexity around this field, but it did not implement the removal requested here. Currentmainstill accepts and documents/testsbuild.binary/binaryinsrc/caution-config, the Procfile migrator, CLI build paths, and e2e fixtures. Keeping this open until the active config surface is removed (with any compatibility/docs/test updates needed for old configs).Fixed by merged PR #372. Verified on current main that build.binary is rejected in caution.hcl, legacy Procfile binary entries no longer create a build block, and the active API/CLI remote-builder request surface no longer sends binary_path for new deployments. Legacy manifest reader compatibility remains intentionally preserved for already-produced manifests.