Repository navigation
Simplify Integration Data Updater and auto-merge on green CI - #1899
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🟡 Changes recommended
Ignoring all merge commits allows the updater to discard maintainer edits recorded during merge conflict resolution.
1 open finding
What changed in this PR
Unblocks the Integration Data Updater after a maintainer uses Update branch on its rolling PR.
Changes:
- Excludes merge commits from the non-bot commit guard.
- Documents the exemption while retaining the existing force-push lease.
| File | Description |
|---|---|
.github/workflows/update-integration-data.yml |
Updates the branch guard to ignore merge commits. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
| else | ||
| git push origin "HEAD:refs/heads/$branch" | ||
| fi | ||
| git push --force origin "HEAD:refs/heads/$branch" |
There was a problem hiding this comment.
why did we drop --force-with-lease?
There was a problem hiding this comment.
It's back, as a bare git push --force-with-lease origin "HEAD:refs/heads/$branch". With no explicit value, git compares against the origin/chore/update-integration-data ref that actions/checkout (fetch-depth: 0) creates, and nothing in the job fetches it again. So the push is rejected if the branch moved or was deleted since checkout.
I checked that against a local bare repo: a new branch, the stuck branch with the human merge commit, a push after the branch moved, and a branch deleted or created mid-run. The PR description lists the results.
The non-bot-commit guard is gone in this version. The PR now merges itself on green CI through .github/policies/auto-merge.yml, so nothing is expected to commit to the branch.
Auto-replied by the GitHub Copilot app
…ration-data-updater-656
Add .github/policies/auto-merge.yml. When the Aspire bot labels a PR ":octocat: auto-merge", the GitOps policy approves it and enables squash auto-merge, so it merges once the required ci-gate check passes. Removing the label disables auto-merge. The sender is limited to aspire-repo-bot[bot] because the main ruleset requires one approval. Simplify the workflow now that nobody commits to the bot branch: - Push with a bare --force-with-lease instead of --force, so the push fails if the branch moved since checkout. - Set the git identity in the commit step instead of a separate step. - Remove the stray-PR cleanup for the legacy timestamped branches. Update the PR body, console warning and update-integrations skill to say the PR auto-merges and that removing the label holds it for review. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 510be1dc-27eb-4efc-a731-1f0065f67252
David Pine (IEvangelist)
changed the title
## Summary Fixes #1960. The Integration Data Updater has failed since #1895 because `generate-package-json.ps1` reads optional `apiReference` metadata directly under `Set-StrictMode -Version Latest`. The catalog omits the property for 209 of 210 entries, so generation aborts before processing packages. - Check property existence before reading `apiReference`. - Keep omitted and explicit `true` entries; exclude explicit `false`. - Add an executable PowerShell regression test that evaluates the production predicate against omitted/false/true fixtures and the real catalog. - Run that regression in the Tools Tests workflow. Failure evidence: [first affected run](https://github.com/microsoft/aspire.dev/actions/runs/38809447050), [latest inspected failure](https://github.com/microsoft/aspire.dev/actions/runs/40403823946/job/121856319285). Related prior repairs: #1813 and #1899; stale rolling updater PR: #1737. ## Validation - PowerShell regression test: passed; real catalog result was `209 included, 1 excluded`. - `PackageJsonGenerator.Tests`: 41/41 passed. - `AtsJsonGenerator.Tests`: 37/37 passed. - `update-integrations.vitest.test.ts`: 50/50 passed. - PowerShell parser for `update-integration-data.ps1`: 0 errors. - `actionlint .github/workflows/tools-tests.yml`: passed. - `git diff --check`: passed. ## Limitations A complete updater `workflow_dispatch` was not run because `main` still contains the failing predicate; running it before this fix lands would reproduce the known failure and cannot validate the branch change. The PR's Tools Tests exercise the exact production predicate, and the next post-merge manual/scheduled updater run should provide end-to-end confirmation. **🤖 Posted by Repository agent (AI Agent)** --------- Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Summary
The Integration Data Updater has failed on every run since a maintainer clicked Update branch on the rolling PR (#1737). That added a human-authored merge commit to
chore/update-integration-data, and the workflow's non-bot-commit guard refused to replace the branch. Data generation itself succeeded.Instead of loosening the guard, this PR removes the reason for it. The bot owns the rolling branch, and its PR merges itself once CI is green.
.github/policies/auto-merge.yml, modeled on aspire-samples. When the Aspire bot labels a PR:octocat: auto-merge, the policy approves it and enables squash auto-merge, so it merges after the requiredci-gatecheck passes. Removing the label disables auto-merge.update-integration-data.yml. There is no non-bot-commit guard, the git identity is set in the commit step, the cleanup for legacy timestamped PR branches is gone, and the push is a baregit push --force-with-leasethat fails if the branch moved since checkout.update-integrationsskill to say the PR auto-merges and that removing the label holds it for review.Differences from the aspire-samples policy
aspire-repo-bot[bot]adds the label. Themainruleset requires one approval, so without this check anyone with triage access could self-approve a PR by labeling it. Deleting theisActivitySendercondition restores the aspire-samples behavior. If the match doesn't fire, the PR waits for a human approval, as it does today.:octocat: auto-merge, which the workflow already applies when it creates the PR.triggerOnOwnActions. The Aspire bot app adds the label here, not the policy service.Things to know
main..github/policies/auto-merge.ymlwas added in Add GitHub stats data for Aspire projects #240 and removed in Content updates for release 13.2 #293, and I didn't find out why.ci-gateis green.Third-party links and affiliations
None.
Validation
actionlint .github\workflows\update-integration-data.yml: passed (exit 0).[System.Management.Automation.Language.Parser]::ParseFileonsrc/frontend/scripts/update-integration-data.ps1: 0 errors.yaml.safe_loadon.github/policies/auto-merge.ymland the workflow: both load, and the policy has the two expectedeventResponderTasks.src/frontend/tests/unit/update-integrations.vitest.test.ts(integration update automation) to the workflow and script: all passed.Merge branch 'main'commit is replaced by one fresh commit on top ofmain. A push after the branch moved is rejected as stale. A branch deleted during the run is not recreated. A branch created during the run is rejected. The next run recovers.git diff --check: clean.frontend-build / Frontend validationpassed, includingpnpm lintandpnpm test:unit, which runsupdate-integrations.vitest.test.ts.GitOps/YmlSchemaValidation("Yaml validation of GitOps managed files") passed too.Not verified: I didn't run the vitest suite or
pnpm buildlocally, becausesrc/frontend/node_modulesisn't installed in this worktree and builds are left to CI. The workflow and the policy only run on schedule,workflow_dispatchand after merge tomain, so neither was exercised end to end.