Add sync.yml workflow to propagate workflow updates across repos #2
Labels
No labels
Compat/Breaking
Compat/Deprecation
Kind
Bug
Kind
Chore
Kind
Documentation
Kind
Enhancement
Kind
Feature
Kind
Investigation
Kind
Question
Kind
Security
Kind
Testing
Meta/Good First Issue
Meta/Help Wanted
Meta/Stale
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Resolution
Confirmed
Resolution
Duplicate
Resolution
Invalid
Resolution
Won't Fix
Status
Abandoned
Status
Blocked
Status
Needs More Info
Status
Needs Triage
No milestone
No project
No assignees
1 participant
Notifications
Total time spent: 11 hours 15 minutes
Due date
Xeplosion
11 hours 15 minutes
No due date set.
Blocks
#3 Add branch protections to template repos to enforce .forgejo as the only source
XeplosionGames/.forgejo
Reference
XeplosionGames/.forgejo#2
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What problem does this solve?
When a workflow file in
.forgejois updated, it must currently be manually copied into every affected repo. This is error-prone and time-consuming at scale.Proposed solution
A
sync.ymlworkflow that triggers on changes toworkflows/orscripts/on main, reads a list of target repos from a config file, and opens a PR in each affected repo with the updated file. PRs not auto-merges — each repo gets a manual review gate.Alternatives considered
Auto-merge across all repos — rejected because a buggy workflow would propagate everywhere instantly with no safety valve.
Additional context
No response
Checklist
Blocking on the submodule investigation (tracked separately). If git submodules can be used to reference
.forgejodirectly from template repos,sync.ymlbecomes unnecessary — files would no longer be duplicated and there would be nothing to sync. Buildingsync.ymlbefore that investigation concludes risks doing work that gets thrown away. Leaving this open pending the outcome of the submodule spike.After further thought, the preferred approach is as follows:
.forgejois the source of truth. Each stack template has a corresponding branch in.forgejo(e.g.template/dotnet,template/script) containing the full contents of that template..forgejopush mirrors eachtemplate/*branch to the corresponding template repo'smainbranch using Forgejo's native branch filter mirroring. A lightweight workflow in each template repo triggers on push tomain(from the mirror) to handle any post-sync steps if needed. This eliminates file duplication, makes.forgejothe single place to update workflows and scripts, and propagates changes to template repos automatically. Supersedes thesync.ymlapproach — updating that issue accordingly. Implementation blocked on confirming Forgejo supports branch-to-branch push mirroring with rename (i.e.template/dotnet→main), which needs verification on our instance.Additional consideration: shared files (issue templates, common workflows like
release.yml, shared scripts likebuild.sh) should not be duplicated across template branches. Async-shared.ymlworkflow onmainwill detect which shared files changed and copy them to the relevanttemplate/*branches based on a mapping defined in async-config.ymlfile at the repo root. A separatesync-template.ymlworkflow then mirrors eachtemplate/*branch to its corresponding template repo. This means changes to shared files only need to happen once onmainand propagate automatically to all relevant templates. Thesync-config.ymlmapping defines which files belong in which template branches, making it easy to add new files or stacks without touching the workflow itself.Blocking on the
.forgejomirror sync system being designed and implemented (tracked separately). Template branches in.forgejoand the corresponding push mirror configuration cannot be set up until the sync workflows (sync-shared.ymlandsync-template.yml) and thesync-config.ymlmapping are defined. Until then, template repos remain the manual source of truth and changes must be copied by hand.Unblocking on the grounds that enough template repos have been created to facilitate sufficient testing of the
.foregjomirror sync system.Progress update: all five template branches (
template-script,template-dotnet,template-node,template-php,template-python) have been created in.forgejo.template-phpandtemplate-pythonrepos still need to be created on Forgejo and marked as template repos. Once those exist, the next steps are configuring the push mirrors in.forgejoSettings → Mirror Settings (one per template repo with the corresponding branch filter), addingpromote.ymlto each template repo's.forgejo/workflows/, and doing an end-to-end test of the full sync flow — push a change to a template branch on.forgejo, verify the mirror triggers, and confirmpromote.ymlsuccessfully promotes it tomainin the target template repo.The sync system this issue originally tracked is fully implemented — shared files propagate to template branches via
sync-shared.ymland from there to template repos viasync-templates.yml.During the process of documenting the sync architecture, two security gaps in the CI/CD deployment model were identified and broken out into dedicated tracking issues:
SSH_PRIVATE_KEYandSSH_USERout of org-level secrets, scopingRELEASE_TOKENandSYNC_TOKEN, CODEOWNERS and branch protection on template branchesauthorized_keyscommand=restrictions, sudoers entries, runner migration#7 is a prerequisite for the deploy key steps in #6. Both are tracked at
Priority/High.Closing this issue as the original sync workflow work is complete. Remaining security work continues in #6 and #7.