Prebuild EnclaveOS components #250
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
public/platform#250
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?
Builders spend like half an hour building locksmith/steve/whatnot. We could totally prebuild those once and just reuse them, for remote builders.
Some thoughts on this: We should have an AWS container registry set up to host images, CI jobs to automatically deploy all verifiable commits to the registry, and make use of those in the enclave-builder.
Implemented on main by PR #468, landed as 3485f577. Platform now prepares/publishes digest-pinned EnclaveOS components and reuses the verified artifacts instead of rebuilding those components for every application. The normal
make upworkflow handles the paired API/component selection.Verified against main
ef44178e11c2782df8e7c834bcfe742f120a8a5e. Freshmake test-bootstrap test-prepare-componentspassed 33 offline tests (15 bootstrap/setup + 18 component preparation); these use fixtures, not live AWS deployments.Closing the prebuild implementation request. Independent TAP-framer source pinning remains tracked separately in #483.