Skip to content

Propagate changes from main into development - #1261

Closed
Wikid82 wants to merge 7 commits into
developmentfrom
main
Closed

Propagate changes from main into development#1261
Wikid82 wants to merge 7 commits into
developmentfrom
main

Conversation

@Wikid82

@Wikid82 Wikid82 commented Aug 19, 2026

Copy link
Copy Markdown
Owner

Automated PR to propagate changes from main into development.

Manually opened because propagate-changes.yml's sensitive-path gate blocked auto-creation — 4 files under .github/skills/ differ between the branches (README.md, utility-bump-beta.SKILL.md, utility-version-check-scripts/run.sh, utility-version-check.SKILL.md), and .github/skills/ is in .github/propagate-config.yml's sensitive_paths list. The gate is all-or-nothing across the whole diff, so those 4 files blocked the otherwise-safe workflow/CI changes from auto-propagating too.

Please review the .github/skills/ diff specifically before merging.

Wikid82 and others added 7 commits August 17, 2026 15:18
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jeremy <jhatfield82@gmail.com>
The repo's default branch is development, but release-please-action
defaults its target-branch input to the repository default branch via
the API regardless of which branch the push trigger fired on. Since
release-please-config.json/.release-please-manifest.json only exist on
main (by design), the action was looking for them on development and
failing with "Missing required manifest config."
Lets a human manually re-fire branch propagation (main -> development)
when the workflow_run trigger doesn't fire on its own, without needing
to re-run the upstream Docker Build workflow. The job's `if:` condition
is extended to admit workflow_dispatch runs, since
github.event.workflow_run is unset in that context.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@github-advanced-security

Copy link
Copy Markdown
Contributor

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

  • The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
  • Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
  • You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

@Wikid82

Wikid82 commented Aug 19, 2026

Copy link
Copy Markdown
Owner Author

Superseded by a new PR carrying the resolved merge — GitHub PRs can't have their head branch repointed, and the head here (main) can't itself receive a merge-into-development commit. Conflicts (a stale comment-placement conflict in propagate-changes.yml, and a modify/delete on release-goreleaser.yml deleted by the release-please migration on main) resolved on a new branch off development.

@Wikid82 Wikid82 closed this Aug 19, 2026
Wikid82 added a commit that referenced this pull request Aug 24, 2026
…th matches

The sensitive-path gate in propagate-changes.yml was all-or-nothing
across the whole diff: a single file matching `sensitive_paths` (in
.github/propagate-config.yml) skipped PR creation for the entire
propagation, even when it was bundled with otherwise-safe changes like
CI or dependency fixes. This already caused a dropped propagation: PR
#1261 needed a human to notice and manually recreate it after 4
unrelated .github/skills/ files blocked the auto-PR, and that manual
PR was later closed unmerged.

Instead of skipping PR creation on a sensitive-path match, still
create the (draft) PR but prepend a warning section to the body
listing the specific matched files and asking for manual review before
merging. PR creation is now only skipped for the pre-existing "not
ahead of base" and "PR already open" cases — never for a sensitive-path
match.
Wikid82 added a commit that referenced this pull request Aug 24, 2026
Previously every auto-propagation PR was opened as a draft with no
path to merging itself, so even the "clean" (no sensitive-path
matches) legs of the chain still needed a human to notice an open
draft PR and manually mark it ready + merge it. That manual step is
exactly the kind of gap that let propagation PRs (e.g. #1261) sit
unmerged.

For PRs with no sensitive-file matches, open them ready-for-review
(draft: false) and attempt to enable GitHub's native auto-merge via
the enablePullRequestAutoMerge GraphQL mutation, requesting
mergeMethod: MERGE — this repo only allows merge commits
(allow_squash_merge/allow_rebase_merge are false), matching the
existing nightly -> main weekly promotion policy of always using
"Create a merge commit". PRs with sensitive-path matches (see previous
commit) stay draft and do not get auto-merge, per Fix 2's intent of
flagging them for manual review rather than merging automatically.

The mutation call is wrapped in try/catch and only logs a warning on
failure — it never fails the workflow job. This matters today because
the repo-level "Allow auto-merge" setting is currently OFF
(confirmed via `gh api repos/Wikid82/Charon --jq '{allow_auto_merge}'`),
so the mutation will reliably fail until a repo admin turns it on
(Settings > General > Pull Requests > Allow auto-merge) — a deliberate,
separate decision, not something this change attempts itself. The code
is correct and inert until that setting is flipped.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants