Prevent builds from running on forks

[elliedori]

Github Actions doesn't currently have an elegant way to prevent builds on forks. Following the suggestion outlined here, I added checks for each job to ensure it only runs on spring-projects/spring-session.

I opened a PR on my forked version as well as updated my forked master, and confirmed that no builds steps ran.

See https://github.com/elliedori/spring-session/actions/runs/236392775 and https://github.com/elliedori/spring-session/actions/runs/236394687 for more.

This PR resolves #1678

[vpavic]

Yeah, this seems like a very unfortunate limitation of GitHub Actions.

With this approach those builds still run, but end up being short-circuited due to the check. Also if you forget to add the check when adding a new job (which isn't unrealistic at all), the problem is there again.

Having a shortcoming like this one, to me GitHub Actions doesn't appear mature enough yet to be a primary CI/build runner.

[elliedori]

You bring up a good point @vpavic. At this point the team has decided on moving forward with Github Actions, so we're currently finding the best ways to adapt it for our use case. If you'd prefer not to see the short-circuited run on your fork, you can also disable Github Actions in your fork of the project.

Hope this helps, and thanks for bringing the original issue to our attention.

[vpavic]

I did that for my fork already, but (as of time of writing) there are 909 other forks out there. 🙂

Keep in mind that this makes it very easy to spam people's inboxes, which is nice way to greet potential contributors.

[elliedori]

Ah that's a good point @vpavic . I have email notifications disabled so I'm not feeling that pain. Are you getting emails even for skipped builds?

For context, the team's been wanting to port builds over the Github Actions for cleaner integration / having everything in one place given that the project lives on Github. If this is creating too much pain for contributors, then your point about not moving over to GA may be a valid one. That would be unfortunate, as we've already invested a lot of time getting GA pipelines up and running for this project and the spring security one.

I'll defer to @eleftherias in this case – what are your thoughts on how we should proceed?

[vpavic]

Are you getting emails even for skipped builds?

That's fully configurable (see here), I personally have it enabled only for failed ones. But someone else might have it enabled for all.

Maybe it's just me, but I really wish Actions were an opt-in feature. Or at the very least if organization/repository owners had control whether Actions are enabled by default for forks. Having to workaround these issues by modifying jobs is not pretty.

[rwinch]

I agree that working around this in the build is not pretty, but it should have very minimal impact to most users. In the long run, I still feel GitHub Actions is where we prefer to run our builds. It has a large community supporting it with lots of integrations. Additionally, as GitHub has become a standard for code management, I think that GitHub Actions will be a standard CI. Finally, it makes sense that users can run the CI on their side. After all, if you fork a project it is nice to know the health of your fork as well.

[vpavic]

I disagree that it makes sense to run the builds on the fork. Fork is just a copy of a project typically created with the intention of contributing to upstream. Changes originating from the fork will get verified either way on the upstream once PR is opened. When that flow completes, vast majority of the forks will become stale (as most folks are not regular contributors) and running (scheduled) builds against those is just wasteful. Forks made with other purpose, such as creating custom builds or diverging the fork completely, will either way require you to set up the CI as if it was a new project.

The default GitHub Actions behaviour for forks is a major annoyance to me as it can quite easily end up being a spam machine, either the way like this project's builds do currently or using something else from the Actions ecosystem e.g. see the PRs Dependabot opened against my Testcontainers fork.

Don't get me wrong, I like GitHub Actions pretty much in general and agree that having CI in the sample place where the code is really nice. After all, that's one of the reasons many preferred Gitlab to GitHub over the years. However, as evident several examples, things are not there yet.

Also I'd be wary about one more thing when moving the CI completely to GitHub Actions - as adoption scales, I don't see it as unlikely that they imposing a limit of minutes to free tier at some point, similarly like Gitlab have recently.

[vpavic]

Speaking of limitations, that didn't take too long. 🙂 This landed in my inbox the other day:

We’re making two changes to the usage policy for GitHub Actions. These changes will enable GitHub Actions to scale with the incredible adoption we’ve seen from the GitHub community. Here’s a quick overview:

• Starting today, scheduled workflows will be disabled by default in new forks of public repositories.
• Scheduled workflows will be disabled in public repos with no activity for 60 consecutive days.

First point is actually a good thing, but second one is a bit upsetting.