Github Doesn't Care

It was also interesting to hear the other side of the story, especially on why things took too long (big internal infrastructure migration at GitHub) or why it feels like the product is not being improved (we both agreed that GitHub should improve their communication). ... Before I rant about GitHub Actions, I'd like to set the context on where this dissatisfaction comes from. My team consists of about 15 engineers constantly pushing to the main branch. Our code lives in a monorepo split per module, which, through trunk based development, gets deployed multiple times a day. … `web-app1` folder. So if my pull request only made changes in `api1` I will never be able to merge my pull request! 🤯 In these two GitHub threads 1, 2 you can see the impact. The bottom line is, that working around this limitation is hacky, difficult to maintain, and costly since you have to run additional pipelines just to determine if a pull request can be merged or not! GitHub should not rely on specific names for the required checks. They can just say - all checks have to pass before you merge. That way, whatever pipelines and checks your pull requests have triggered will be considered mandatory. It's been almost 3 years since these issues were raised, and nothing changed yet! My impression is that when your pipeline grows, it becomes more and more difficult to manage it with GitHub Actions. Here is an example workflow that can be called from other workflows, can be triggered manually, and triggers when someone pushes to the master branch. … What I notice doing more and more is that I have to add lots of if statements such as this. ` if: ${{ github.event_name == 'push' || inputs.target_environment == 'production' }}` While I could split this into multiple workflows with different triggers, then I'm getting more and more files to maintain. A workflow reuse should be a one-liner but I always have to write more lines and a lot of duplicated statements such as workflow name, `secrets: inherit` etc. Our `.github` folder already contains 30+ files. Another pitfall that happens often is the `needs` clause. When you are refactoring and removing jobs, it's easy to forget to update this clause and subsequent steps. While there are linters available, they are not perfect. The sad part is that I can only see mistakes when I push the workflow, I'd expect to know about this way earlier. … Of all the pain points, this is the worst one. It seems that GitHub doesn't care about fixing any of these issues or improving its product. Some of the threads have been open for years without any action taken by GitHub. A lot of these issues have been recently closed by GitHub causing a backlash from the community. There are no signs that these will be addressed based on their public roadmap. Considering all the problems listed, with the lack of motivation from GitHub I'd think twice before using GitHub Actions again. The CI/CD product space offers a lot of options such as Gitlab, Jenkins, TeamCity, etc.