Repository navigation
ci(marketplace-pre-release): track daily pre-releases across manual and scheduled runs - #1834
Conversation
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Manual dispatch must be restricted to main to prevent publishing unmerged refs.
Review effort: Balanced
Findings: 1
What changed in this PR
Adds manual triggering for the Marketplace pre-release workflow.
Changes:
- Enables
workflow_dispatchalongside the daily schedule.
| File | Description |
|---|---|
.github/workflows/marketplace-pre-release.yml |
Allows manual pre-release workflow runs. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
renkun-ken
left a comment
renkun-ken
left a comment
There was a problem hiding this comment.
Two issues need addressing before enabling manual publishing.
- Restrict publishing to
main. I confirmed the existing branch-selection finding:prepare.ifchecks only the repository, and the reusable verification workflow plus publishing checkout use the dispatch ref. Selecting a feature branch can therefore publish unmerged code into the public daily pre-release channel. Extend theprepareguard withgithub.ref == 'refs/heads/main'so downstream verification and publishing are skipped for other refs. - Account for manual publications in the daily bookkeeping. The inline comment describes a reproduced sequence where a successful manual release causes a newer main commit to remain unpublished, even after the next scheduled run.
Validation: parsed the exact PR workflow, executed its preparation shell script against mocked GitHub API run history, and checked the installed vsce/ovsx duplicate handlers. The five existing extension-version tests pass. No publishing workflow was dispatched.
| on: | ||
| schedule: | ||
| - cron: '23 3 * * *' | ||
| workflow_dispatch: |
There was a problem hiding this comment.
[P2] Track manual publications before deduplicating daily versions
Adding dispatch exposes a gap in prepare: the previous-run query still filters with event=schedule, so successful manual publications are invisible. For example, a manual run publishes main SHA A as 3.1.20261006 before the daily cron; SHA B then lands, and the scheduled run builds B with the same version. Both registry commands return success via --skip-duplicate while leaving A published. The next day, prepare sees that successful scheduled run with head_sha == B and skips B again, so B stays unpublished until another commit arrives. I reproduced this three-run sequence using the exact preparation script. Update publication tracking to include dispatches and distinguish actual publications from successful no-op runs, so a duplicate-version skip cannot mark an unpublished SHA as released.
renkun-ken
left a comment
renkun-ken
left a comment
There was a problem hiding this comment.
Reviewed commit 6f6a302. The main guards on both prepare and publish address the branch-selection finding.
The [P2] publication-bookkeeping issue remains open (original finding). I reran the exact preparation script from this revision against mocked GitHub API history and reproduced:
- A manual run publishes main SHA A as
3.1.20261006. - SHA B lands before the daily cron. The scheduled run builds B with the same version;
--skip-duplicateleaves A published but makes the run successful. - The next day's scheduled run sees the previous successful scheduled run's SHA B and skips it, so B remains unpublished until another commit arrives.
The query at lines 31–33 still excludes workflow_dispatch runs and the SHA check at line 37 still treats a successful no-op as a publication. Please track actual publications across both trigger types and avoid marking a duplicate-version skip as a release of a different SHA. Simply adding dispatches to the query is insufficient if successful preparation-only skips can still become the latest publication record.
Keeping the changes request for this remaining issue. Validation used the current workflow's shell script with mocked API history and modeled registry duplicate behavior; no publishing workflow was dispatched.
eitsupi
changed the title
eitsupi
changed the title
renkun-ken
left a comment
renkun-ken
left a comment
There was a problem hiding this comment.
Reviewed dd5c709. Both earlier findings are addressed: publication stays restricted to upstream main, and the history helper considers publishing steps across manual and scheduled runs without treating preparation-only skips as releases.
Verified the original sequence now behaves correctly: a manual publication reserves its UTC date, the same-day scheduled run skips, and the unpublished newer SHA remains eligible the next day. Also checked partial failures, original-run retries, completed-run retries, and the publish-job eligibility recheck.
Validation: all 18 helper tests passed, eight additional process-level helper checks passed using mocked API history with real jq projection and GitHub output formatting, and the API adapter worked against read-only GitHub run/job responses. All current PR checks are green. No remaining actionable findings. No publishing workflow was dispatched.
Enable manual pre-releases on
main, sharing the existing one-release-per-UTC-date limit with scheduled runs.The history helper checks actual publishing steps across both trigger types and all attempts, so successful no-op runs cannot mark an unpublished SHA as released. Partial failures reserve the date for the original run's retry, and the publish job rechecks eligibility when rerun.
For long idle periods, consecutive same-SHA runs are searched from their earliest run, avoiding a job-history request per skipped day. Run history is fetched in bounded pages.