Repository navigation
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/24712
Note: Links to docs will display an error until the docs builds have been completed. ❌ 3 New Failures, 1 Unrelated Failure, 12 Unclassified FailuresAs of commit 80d6309 with merge base 60a8b5f ( NEW FAILURES - The following jobs have failed:
UNCLASSIFIED FAILURES - DrCI could not classify the following jobs because the workflow did not run on the merge base. The failures may be pre-existing on trunk or introduced by this PR:
BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
This PR needs a
|
f41530e to
54c042d
Compare
54c042d to
0ac1cb9
Compare
0ac1cb9 to
dac84a5
Compare
dac84a5 to
bf3f4b5
Compare
|
@claude review effort=max |
|
Claude finished @rascani's task in 39m 6s —— View job Claude finished @rascani's taskThis PR adds a tag-driven workflow that packs, tests, and uploads PR Review: #24712Summary
Request Changes. The blocking problems:
Several release-only paths also run for the first time at a real tag. I could not check compote 3.1.2, the registry API, or Code Quality
Infrastructure
Testing
API Design
Security
Thread Safety
Specific Comments
RecommendationRequest Changes Three findings block approval:
The rest are minor. The Infrastructure and Testing items are still worth fixing before merge, because the first RC tag is the first time those paths run. |
|
@claude review effort=max |
|
Claude finished @rascani's task in 37m 54s —— View job This PR adds a tag-driven workflow that publishes PR Review: #24712SummaryFor each RC tag, release tag, or respin dispatch,
Request Changes. Three findings block approval:
Several release-only paths also run for the first time at a real tag. I reviewed all nine changed files. Some things can't be checked offline:
Findings that depend on these are marked suspected or low confidence. Code Quality
Infrastructure
Testing
API Design
Security
Thread Safety
Specific Comments
RecommendationRequest Changes These findings block approval:
The rest are minor. The Infrastructure and Testing items are still worth fixing before merge, because the first RC tag is where those paths first run. |
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 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 both registries. 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 nightly's build mode runs the same file check against the mirror, so it is exercised before the first upload. The consumer takes the registry as -DET_COMPONENT_REGISTRY_URL. Uploads go through .ci/scripts/upload_espressif_idf_component.sh, which the nightly's dry-run job now shares. It installs the component manager from a hash-locked requirements file, and the two upload jobs pin their actions by commit, since anything they run could mint a registry token. 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 nightly runs the same release-stamp checks every day, so a change that would break them shows up before a real tag. Runs share a concurrency group per tag or branch, so a run waiting for an approval never cancels another tag's. The manifest names production as esp-nn's registry, because the staging registry records a dependency without one as its own, and staging has no esp-nn; the component manager treats that as the same source as an unnamed dependency on the default registry. The README's runbook covers the one-time setup, in order: the protected environment first, since GitHub creates an unprotected one as soon as a workflow names it, then the staging namespace, then each registry's trusted uploader, which 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. Authored with Claude Code.
bf3f4b5 to
80d6309
Compare
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 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 both registries. 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 nightly's build mode runs the same
file check against the mirror, so it is exercised before the first upload.
The consumer takes the registry as -DET_COMPONENT_REGISTRY_URL.
Uploads go through .ci/scripts/upload_espressif_idf_component.sh, which the
nightly's dry-run job now shares. It installs the component manager from a
hash-locked requirements file, and the two upload jobs pin their actions by
commit, since anything they run could mint a registry token. 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
nightly runs the same release-stamp checks every day, so a change that
would break them shows up before a real tag. Runs share a concurrency group
per tag or branch, so a run waiting for an approval never cancels another
tag's.
The manifest names production as esp-nn's registry, because the staging
registry records a dependency without one as its own, and staging has no
esp-nn; the component manager treats that as the same source as an
unnamed dependency on the default registry.
The README's runbook covers the one-time setup, in order: the protected
environment first, since GitHub creates an unprotected one as soon as a
workflow names it, then the staging namespace, then each registry's
trusted uploader, which 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.
Authored with Claude Code.