Investigate using git submodules to eliminate workflow drift between .forgejo and template repos #12

New issue

Open

opened 2026-05-25 01:30:26 -06:00 by Xeplosion · 0 comments

Xeplosion commented

2026-05-25 01:30:26 -06:00

Owner

What question are we trying to answer?

Can .forgejo be referenced as a git submodule inside each template repo so that workflow and script updates propagate automatically rather than requiring manual copying or a sync workflow?

Why does this matter?

Currently workflow and script files are duplicated across .forgejo and every template repo. Any change to a canonical file in .forgejo must be manually mirrored into template-script, template-dotnet, etc. This will only get harder as the number of template repos and workflows grows. The sync.yml approach (tracked separately) solves this via automation but still duplicates files. A submodule approach would eliminate duplication entirely — template repos would reference .forgejo directly and git submodule update would be all that's needed to pull in changes.

Scope and time box

Research whether Forgejo Actions workflows and scripts can be resolved correctly when sourced from a submodule path (e.g. .forgejo-canonical/workflows/deploy-production.yml) rather than .forgejo/workflows/. Determine if Forgejo supports workflow files outside the standard .forgejo/workflows/ path, and if not, whether symlinks inside .forgejo/workflows/ pointing to submodule files would work. Output is a recommendation to proceed or abandon in favor of sync.yml.

Definition of done

A written recommendation with findings, either a proof of concept branch or a clear explanation of why it won't work.

Checklist

The question is clearly defined
There is a time box or deadline in mind
I know what the output should look like

### What question are we trying to answer? Can `.forgejo` be referenced as a git submodule inside each template repo so that workflow and script updates propagate automatically rather than requiring manual copying or a sync workflow? ### Why does this matter? Currently workflow and script files are duplicated across `.forgejo` and every template repo. Any change to a canonical file in `.forgejo` must be manually mirrored into `template-script`, `template-dotnet`, etc. This will only get harder as the number of template repos and workflows grows. The `sync.yml` approach ([tracked separately](https://git.xegames.online/XeplosionGames/.forgejo/issues/2)) solves this via automation but still duplicates files. A submodule approach would eliminate duplication entirely — template repos would reference `.forgejo` directly and git submodule update would be all that's needed to pull in changes. ### Scope and time box Research whether Forgejo Actions workflows and scripts can be resolved correctly when sourced from a submodule path (e.g. `.forgejo-canonical/workflows/deploy-production.yml`) rather than `.forgejo/workflows/`. Determine if Forgejo supports workflow files outside the standard `.forgejo/workflows/` path, and if not, whether symlinks inside `.forgejo/workflows/` pointing to submodule files would work. Output is a recommendation to proceed or abandon in favor of `sync.yml`. ### Definition of done A written recommendation with findings, either a proof of concept branch or a clear explanation of why it won't work. ### Checklist - [x] The question is clearly defined - [x] There is a time box or deadline in mind - [x] I know what the output should look like

Rows
Columns