The schedule ci trigger
Something came up in a repo derived from this template, and I wanted to
check my understanding, since I suspect the current setup is deliberate.
mattermost-plugin-user-attribute-sync-starter-template
inherited .github/workflows/ci.yml as-is, including the daily schedule
trigger. GitHub automatically turns off workflows containing a schedule
trigger when a public repo has no activity for 60 days, which happened to that
repo in January. The surprising part is that this does not just stop the
nightly runs. It disables the whole workflow file, so pull_request stopped
working too. Three pull requests were then opened and merged with no build,
lint, or tests, and it went unnoticed.
My guess is the nightly run is a health check for this template itself. It
calls plugin-ci.yml@main, which is a moving reference, and the dependencies
move too, so a nightly build catches upstream breakage before someone starts a
new plugin. That seems useful, and the runs here are green.
So the question is whether the schedule was meant to be inherited by derived
repos. I ask because plugin-ci.yml has a run-scheduled input for forks and
a condition that skips scheduled runs unless the owner is mattermost, which
suggests inheritance was already known to be awkward. That owner check does not
help Mattermost-owned derived repos, though. The scheduled runs there were
created and then all skipped, so they produced no signal while the repo still
carried the risk of losing its pull request checks.
The master push trigger
There is a second problem in the same file that seems worth raising. This
template was created in 2018 and its default branch is master, so ci.yml
has push: branches: [master]. GitHub changed the default branch name for new
repositories to main in October 2020, so any repo created from this template
since then almost certainly defaults to main and inherits a push trigger that
can never match. The derived repo above was created in November 2025 and hit
exactly that, so post-merge runs had never worked there at all. Unlike the
schedule issue, this one is silent from day one rather than after 60 days.
Does it make sense to change either of these, or are they known tradeoffs?
🤖 Generated with Claude Code,
The
scheduleci triggerSomething came up in a repo derived from this template, and I wanted to
check my understanding, since I suspect the current setup is deliberate.
mattermost-plugin-user-attribute-sync-starter-template
inherited
.github/workflows/ci.ymlas-is, including the dailyscheduletrigger. GitHub automatically turns off workflows containing a
scheduletrigger when a public repo has no activity for 60 days, which happened to that
repo in January. The surprising part is that this does not just stop the
nightly runs. It disables the whole workflow file, so
pull_requeststoppedworking too. Three pull requests were then opened and merged with no build,
lint, or tests, and it went unnoticed.
My guess is the nightly run is a health check for this template itself. It
calls
plugin-ci.yml@main, which is a moving reference, and the dependenciesmove too, so a nightly build catches upstream breakage before someone starts a
new plugin. That seems useful, and the runs here are green.
So the question is whether the schedule was meant to be inherited by derived
repos. I ask because
plugin-ci.ymlhas arun-scheduledinput for forks anda condition that skips scheduled runs unless the owner is
mattermost, whichsuggests inheritance was already known to be awkward. That owner check does not
help Mattermost-owned derived repos, though. The scheduled runs there were
created and then all skipped, so they produced no signal while the repo still
carried the risk of losing its pull request checks.
The
masterpush triggerThere is a second problem in the same file that seems worth raising. This
template was created in 2018 and its default branch is
master, soci.ymlhas
push: branches: [master]. GitHub changed the default branch name for newrepositories to
mainin October 2020, so any repo created from this templatesince then almost certainly defaults to
mainand inherits a push trigger thatcan never match. The derived repo above was created in November 2025 and hit
exactly that, so post-merge runs had never worked there at all. Unlike the
schedule issue, this one is silent from day one rather than after 60 days.
Does it make sense to change either of these, or are they known tradeoffs?
🤖 Generated with Claude Code,