Skip to content

Should the daily schedule trigger live in the template's ci.yml? #247

Description

@davidkrauser

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,

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions