![]() ![]() The problem is, GitHub Actions does not provide more powerful runners. On the graphics above we saw that our build time got significantly worse, but with a much less powerful VM, which seems totally coherent. The builds were significantly cheaper, but we had no plan to prioritize lower cost over a worse feedback loop on our pull requests. In particular, the gradle build step lasted around 16 minutes on GitHub Actions versus 7 minutes on Cloud Build. So I compared the performance of both, focusing on the time wasted on each workflow run and their cost.Ĭomparison between GitHub Action and Google Cloud Build for our workflowsĪs you can see, each build lasted about twice as long as previously □. Build timeĪs I said before, my first goal was to provide the team with a CI that would be at least as good as the former one. Instead, we just need to maintain one yaml file that defines the workflows, the runners it uses, the events that trigger it. having the information split between yaml files for the workflows, web interface for the triggers, and again dockerfiles.having to maintain complex docker images.We got rid of what I identified as the main pain points of our former CI on Google Cloud Build : In terms of maintenance, the whole team found it easier to read, write and customize. As a result, the day to day developer experience remained the same, meaning that we didn’t miss anything we were used to. This first version of our brand new CI provided all the features our former CI did. Step back and analyse the results Features and maintenance Here are the steps of our former CI flow: ![]() □ If you are new to GitHub Actions, I recommend the official documentation or the Learning Lab. Each runner can run a single job at a time.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |