You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f41530e
Browse filesBrowse the repository at this point in the historyBrowse files
publish-esp-idf.yml publishes pytorch/executorch to the ESP Component
Registry. An RC tag vX.Y.Z-rcN publishes X.Y.Z-rc.N to the staging
registry, a release tag vX.Y.Z publishes X.Y.Z to staging and then
production, and a manual run on release/X.Y publishes a packaging respin,
X.Y.Z~N. Other v* tags publish nothing.
The workflow packs the component once, under the generator's release-stamp
checks, and asserts the version matches the tag. Before anything is
uploaded, it builds and runs that archive in every consumer configuration
on ESP-IDF 6.0.1 and 6.1 and validates it with the registry. Each upload
waits for a reviewer of the esp-component-registry environment. After each
upload, the new registry mode of test_espressif_idf_nightly.sh polls until
the registry lists the version, builds the consumer with pytorch/executorch
resolved from that registry, checks that the registry served the tested
archive's files (apart from the examples' manifests, which the registry
rewrites to drop override_path), and runs it on the emulator. Production waits for that
check on staging. The consumer takes the registry from
ET_COMPONENT_REGISTRY_URL.
Uploads go through .ci/scripts/upload_espressif_idf_component.sh, which the
nightly's dry-run job now shares. It authenticates with the job's GitHub
OIDC token for the registry, the way espressif/upload-components-ci-action
does, and uploads the archive that was tested, with --allow-existing so a
failed run can be rerun. A version already on the registry is kept, so a
rerun that packed different bytes fails the registry check instead of
shipping them. prepare now records the commit and generator path
in that archive at pack time, because compote applies them only when it
packs. Manual runs validate without uploading unless dry_run is cleared.
Pull requests that touch the workflow run it as a dry run that stamps a
release version at a throwaway local tag, because workflow_dispatch cannot
run before the workflow is on main and the release stamp's clean-tree check
would otherwise first run on a real tag. Publishing runs share one
concurrency group, so two runs never upload the same version at once.
A respin may now also change the component's CI (its .ci/scripts and
workflows) since the release tag, so a release whose publishing broke can
be published as X.Y.Z~1 once the pipeline is fixed. The manifest names
production as esp-nn's registry, because the staging registry records
dependencies without one as its own, and staging has no esp-nn.
The first upload needs these setup steps. Staging needs the pytorch
namespace and pytorch/executorch, which production already has. On each
registry, pytorch/executorch's trusted uploader names
pytorch/executorch as the repository and esp-component-registry as the
environment, with no branch, because the registry cannot pin a workflow
and tag pushes carry no branch. A repo admin creates that environment with
reviewers, self-review prevented, no admin bypass, and deployments limited
to v* tags and release/* branches. Approve the staging upload once the
nightly matrix is green on the release commit, and the production upload
once the version on staging has been checked.
Authored with Claude Code.
0 commit comments