You should enable CI on your forks manually

Alexey Inkin
2 min readJun 25, 2023

--

I have been embarrassed recently. I tried to contribute to a high-profile guy’s repository, and had been repeatedly pushing faulty commits and asking him to review them multiple times.

I thought I was diligent by running a linter before pushing, but he had an advanced CI beyond that. I could not run it on my PR myself because I am not yet a contributor:

Many of GitHub repositories are configured so that the CI workflows do not run automatically on PRs of first-time contributors.

I thought that a copy of the same CI would just run on my fork automatically, and since the commit was not red, I thought it’s safe to ask the guy to trigger his CI.

What I overlooked is that the commit was not green either. When I finally opened “Actions” in my fork, I have learned that GitHub never ran the CI:

I had to manually enable the workflows by clicking the green button.

Even that was not enough in my case, because the workflow I needed had cron as one of its triggers, so I had to explicitly allow it:

A workflow with cron among other triggers will not run on any triggers until manually enabled.

I guess this is to save your runner quota. If the workflows were enabled by default, you could have accidentally forked a repository with heavy workflows running frequently by cron, and it would deplete your quota.

So make sure you enable workflows in your fork before pushing any PRs to save time of other developers.

--

--

Alexey Inkin

Google Developer Expert in Flutter. PHP, SQL, TS, Java, C++, professionally since 2003. Open for consulting & dev with my team. Telegram channel: @ainkin_com