{"id":443,"date":"2024-06-26T14:41:24","date_gmt":"2024-06-26T14:41:24","guid":{"rendered":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/?p=443"},"modified":"2024-06-26T15:16:32","modified_gmt":"2024-06-26T15:16:32","slug":"adopting-a-more-rational-use-of-continuous-integration-with-github-actions","status":"publish","type":"post","link":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/2024\/06\/26\/adopting-a-more-rational-use-of-continuous-integration-with-github-actions\/","title":{"rendered":"Adopting a more rational use of Continuous Integration with GitHub Actions"},"content":{"rendered":"<p>by <strong>Chris Cave-Ayland<\/strong><\/p>\n<p>In the Imperial RSE Team we make extensive use of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Continuous_integration\">continuous integration<\/a> (CI) with<br \/>\n<a href=\"https:\/\/docs.github.com\/en\/actions\">GitHub Actions<\/a>. We use CI to ensure our projects build and are correct across a range of<br \/>\nscenarios (OS, python version, dependency version, etc.). Widely accepted wisdom is that<br \/>\nit is best practice to catch issues early via frequent and thorough CI rather than to<br \/>\ncatch them later. This must however be set against the monetary and environment cost of<br \/>\nrunning unnecessary compute workloads on every push to GitHub. In particular, the<br \/>\npricing structure of GitHub Actions means workloads run on Windows and MacOS are more<br \/>\ncostly (certainly financially and presumably environmentally). This is particularly the<br \/>\ncase for private repositories for which Imperial has a fixed budget of minutes.<\/p>\n<p><!--more--><\/p>\n<p>Some recent issues with hanging GitHub Actions runners caused us to review our approach<br \/>\nto CI across our full set of projects. We decided there is no one size fits all<br \/>\napproach, but we should be more parsimonious in our use of CI by default whilst<br \/>\nreviewing the need for more comprehensive CI as issues arise in individual projects.<\/p>\n<p>To come up with our new standard approach we considered the key points in development<br \/>\nwhere CI can be used. Under our typical development practices, there are four times<br \/>\nwhen CI workflows may be run. Decreasing in frequency of occurrence:<\/p>\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li>Push to feature branches.<\/li>\n<li>(non-draft) Pull request against primary development branch.<\/li>\n<li>Push to primary development branch.<\/li>\n<li>Before release.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>The most parsimonious viable approach to CI that we landed was:<\/p>\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li>Not running workflows on pushes to feature branches.<\/li>\n<li>Running QA and test workflows under a single scenario (eg. in Linux with Python 3.12) on pull request.<\/li>\n<li>Not running workflows on pushes to primary development branch.<\/li>\n<li>Running test workflows under a full range of scenarios before release.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>From this starting point we can revise the extent of testing performed at each stage<br \/>\nbased on experiences on the project e.g. if we consistently experience issues with a<br \/>\nparticular OS at release time then we can consider testing on that more frequently.<\/p>\n<p>The above has wider implications for our development practices:<\/p>\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li>Branch protection rules must be used to prevent direct pushes to main\/dev and to require &#8220;branches to be up to date before merging&#8221; and these should be adhered to strictly.<\/li>\n<li>Account for potential issues arising around releases. You should build in time\/manage expectations to fix anything that might come up.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>We also identified several other key best practices that help reduce our footprint:<\/p>\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li style=\"list-style-type: none\">\n<ul>\n<li>The default timeout for workflows on GitHub hosted runners is 6 hours. This is far larger than it needs to be and in the event of a hanging runner can be very expensive. All jobs should have reduced a timeout set (unfortunately this has to be done on a per-job basis), but especially those on non-linux runners.<\/li>\n<li>Use caching wherever possible. This can be particularly useful for <a href=\"https:\/\/github.com\/actions\/setup-python#caching-packages-dependencies\">Python dependencies <\/a>or build artifacts (via ccache).<\/li>\n<li>Consider carefully what OS&#8217;s, Python versions, etc. your project actually needs to support and only test against those. Also bear in mind that it may not be necessary to do a full &#8220;matrix&#8221; of tests e.g. all different OS&#8217;s with all different Python versions.<\/li>\n<li>Enable manual execution of workflows (via the `workflow_dispatch` trigger) so you can run things as desired. This may be useful to e.g. get early warning of issues before attempting to create a release or to force checks to run against a draft PR.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>In summary, CI is a valuable tool to ensure the correctness of software projects, but<br \/>\nthere is some low hanging fruit ready to pick to make a more rational use of it<br \/>\nsaving time, money and reducing the environmental impact of the process.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>by Chris Cave-Ayland In the Imperial RSE Team we make extensive use of continuous integration (CI) with GitHub Actions. We use CI to ensure our projects build and are correct across a range of scenarios (OS, python version, dependency version, etc.). Widely accepted wisdom is that it is best practice to catch issues early via [&hellip;]<\/p>\n","protected":false},"author":904,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[317617,317614,317616,317615],"class_list":["post-443","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-budget","tag-continuous-integration","tag-environment","tag-github-actions"],"_links":{"self":[{"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/posts\/443","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/users\/904"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/comments?post=443"}],"version-history":[{"count":7,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/posts\/443\/revisions"}],"predecessor-version":[{"id":450,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/posts\/443\/revisions\/450"}],"wp:attachment":[{"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/media?parent=443"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/categories?post=443"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs-staging.imperial.ac.uk\/research-software-engineering\/wp-json\/wp\/v2\/tags?post=443"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}