Looks like this blog post is not valid anymore. July 2020 GitHub released proper support for forks https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/ which is super awesome!
This post was supposed to be about something totally different. It was supposed to be a post about how easily you can automate workflows in your project using GitHub Actions. It was...but I was in the middle of my task when I planned this post. Now I'm pretty much done and I'm disappointed with GitHub for the very first time.
GitHub Actions got my ❤️ since it was announced. I could not play with it. I had no use case for it as in my previous project we were bound to a specific CI tool. Then I moved to work on AsyncAPI and I was super happy to introduce GitHub Actions there.
First workflow with GH Actions ❤️
I'm an automation freak. I hate to do the same things twice, and that is why the first thing I wanted to improve was Docker image publishing.
Oh man, I loved it. Starting with GitHub Actions was so easy. Googling out basics was super simple. They also have this super awesome UI for noobs that just started with Actions. Even editing of the workflow files looks different then with other files. There is a dedicated view for workflows with fancy autocomplete and linting. Well done GitHub, well done!!! Using GitHub is as awesome as using TravisCI, but without leaving GitHub UI.
You can imagine that with such a level of excitement when I've learned about GitHub Actions Hackathon I was like "Hell yeah, I'd love to participate".
Now I'm puzzled and lost my motivation to participate in the hackathon. Why? cause I spent some time introducing different workflows and I've learned about some limits that make GitHub Action not as cool as I thought in the beginning.
All things GitHub Actions
After my first task with GitHub Actions and a review of available actions my statement was clear: all automation must go through GitHub Actions.
What use cases I had in mind?
Welcome message
Writing a welcome message to the first-time contributors is a very useful feature. You can not only use it to say usual Hi but also to share important links with new joiners. In the case of AsyncAPI, I wanted to make sure we welcome them with a link to a page that explains all the different ways people can interact with AsyncAPI community.
Auto-labeling
Automated labeling of pull requests depending on what files were modified helps with project maintenance. Not only labeling basing on files modified but also other reasons, like labeling based on the size of the change. It speeds up the maintenance of the project at scale.
Pull request merge
Triggering pull request merge with a specific label is a great step to improve the security of your GitHub organization. To be 100% sure you are secure from vulnerabilities (someone left your organization and you forgot to change his access right) and also you're own mistakes, you should not have write access to repositories. Write access should belong only to a bot that can merge pull requests.
The moment of 💔
Adding all those different actions was super easy, especially thanks to the awesome community of devs that added so many different GitHub Actions to the marketplace. I tested easily all changes on my fork. I created pull requests in a fork and proved the setup works like a charm.
Everything was great until I started using them in a real environment. Real environment meaning a project, in an organization that works with contributions through forks like all the other projects on GitHub.
All those workflows are not supported when pull requests come from forks.
The reason is that the default GITHUB_TOKEN used in a fork-workflow has read-only rights. You can, of course, provide your own secrets, like MY_GITHUB_TOKEN but it is pointless effort as custom secrets are not available in a fork-workflow.
It is like the GitHub team behind the feature never worked in open-source, or their security team is stronger than product management. I don't believe any of these can be true. It is GitHub after all, you kind of trust the brand. I'm truly afraid the reason is money. On enterprise-level, you almost never work with fork-workflow, so basically those that pay, do not really need strong support for forks.
Did we broke up?
There are relationships where you wish to never see your ex again. Not in this case. My heart is broken, I'm disappointed, but I want us to stay friends. I hope this is a temporary issue and that GitHub fixes it, otherwise they will lose a lot on adoption.
I will still use GitHub Actions for release automation and write about it soon.
Now, come on man, you criticize, you're such a smart ass, but this flow has limits for a reason, this is a real security threat. Someone could fork the repo, modify workflow in the way that he can read the secret and exploit the system secured with it. (a very possible comment that I could get in this post)
This is a valid point, but very easy to solve with current GitHub functionality. In my previous project, I used Prow that was built for Kubernetes to test it and maintain the community on a very high scale. Prow also has to support fork-workflow.
How the Kubernetes test-infra team solved the security concern? They do not trigger CI jobs if the pull request was not created by the member of the organization. Organization member, after checking that the pull request is not modifying GitHub Action workflow, must comment on the pull request to trigger CI with a message like /ok-to-test. As simple as that.
GitHub can go a step further here and integrate GitHub Actions with code owners feature. You should be able to specify in CODEOWNER file a more limited group of people that can approve changes in workflows and trigger them with /ok-to-test.
I hope that, by accident, I revealed how the GitHub Actions team is already working on fixing this limitation 😃. I really like this functionality and want to also use it for managing and supporting AsyncAPI community. I'm looking forward to doing all the things with GitHub Actions.
Top comments (0)