Since its release in November 2019, GitHub Actions has continued to gain in popularity. Fully 72% of AppMap users tell us that their team is using GitHub Actions! I've been personally using GitHub Actions intensively for about six months, and it feels to me like a substantial leap forward in automation technology. Why? As CI/CD has gained importance, it has increasingly become disconnected from the productivity needs of developers, primarily due to security concerns. I find that GitHub Actions allows me to automate code in innovative ways that are not possible within the confines of traditional CI/CD pipelines.
How GitHub Actions works
In case you're new to GitHub Actions, here's a quick overview:
- A GitHub Action is a code snippet that runs on GitHub-hosted infrastructure (or you can provide your own compute).
- GitHub Actions can be combined together into sequences called Workflows.
- A GitHub action can be defined in a GitHub repository, and imported by other projects. So they are highly sharable and reusable.
- A Workflow is a YAML file that lives in the
.githubfolder of the code itself. - Because a workflow is a git-managed file, each version of the code can have its own workflows. That makes it easy to try out new workflows on a branch, and then merge them to
mainwhen they are debugged. - There are lots of different ways to trigger workflows. Common triggers include "run on pull request", "run on push", and "run on schedule".
With this combination of features, GitHub Actions gives developers the power to easily create just about any kind of code automation.
How we got here
I'm, um, old enough that when I started my career, manual builds were the norm. Build automation tools like Jenkins came along pretty soon afterwards, and brought repeatability to the build + test + package cycle.
Deployment was still almost always a manual step. The next big step was CI/CD, which moved build automation to cloud-hosted infrastructure and also automated the deploy steps - this, of course, was made possible by cloud computing infrastructure: Amazon EC2 and all the services that derived from it.
Trouble in paradise
CI/CD became the core of DevOps, which expanded automation into many new areas. Most of this growth and expansion has been very positive, but the rigor of the automation has actually had some drawbacks for developers. Why? Because CI/CD has such so much power to package and deploy code, it's also become an area of high security risk.
Hackers quickly identified and exploited multiple avenues of attack:
- Inject malicious code directly into the target software as it's being built.
- Use a compromised CI job is a stepping-stone for access to production systems.
- Use inside knowledge of the code to build the perfect exploit or backdoor.
- Attack the CI/CD vendor directly to obtain credentials in bulk. (Four well-known vendors in the CI/CD space have all been breached in the last decade).
Security is a real concern with CI/CD systems. As a result, they are now highly protected. This is necessary - but it's also meant that CI/CD is not a developer-friendly environment anymore. CI/CD is too tightly controlled to be a good place for developers to try out new experiments in code automation.
GitHub Actions to the rescue
This is where GitHub Actions comes in. A GitHub Action does not need to be part of the "blessed" CI/CD process. It can perform any kind of ad-hoc job that a developer might want it to. For example, there are GitHub Actions to report test status, inject comments into commits and PRs, synchronize with other systems, generate code, send notifications, look for bugs, etc. And it can do these things "off to the side", out of the way of the official pipeline job. It's no longer necessary to modify the master build file (think: travis.yml, Jenkinsfile, .circleci) in order to try out some new code automation.
Since Actions are controlled by YAML files that any developer can create and modify - and they run in the cloud with direct and easy access to project source code - GitHub Actions combine power and safety in a way that's not found either in local developer environments or in traditional CI/CD tools.
Powerful, tune-able performance
As a developer, you have a good understanding of performance considerations such as CPU capabilities, memory use, and parallelization. So, you'll be glad to know that GitHub Actions is powerful enough to let you control and optimize exactly how your workflow uses and consumes compute and storage.
Each Workflow runs on a pre-defined runner instance, which is basically a container running with a pre-defined allocation of CPU cores and amount of memory. So you can run small, lightweight jobs with little cost.
Is your Workflow slow and sluggish? You've got options; several options in fact. First, you can bump the workflow up to a larger runner instance. How does 64 cores and 256GB of RAM sound? You can get that. What if the code you are running doesn't scale that well with cores? Well, you can apply matrix build strategies as well.
You can store and retrieve data within and across workflows. Both a cache store and artifact store are available. The cache is really fast, and it can only be accessed from within Workflows. Artifacts are slower, but they can be accessed from anywhere using the GitHub REST API. Cache expiration times and artifact retention times are both customizable, so you can tune the amount of money you are spending on these storage resources.
Proceed! (With caution)
While it is separate from the official CI/CD pipeline, the privileged operation of GitHub Actions does still pose a security risk. GitHub Actions have access to the code; can commit and push code; can be given access to secrets that may be mishandled. Recognizing this, GitHub provides repository and organization settings that can be used to control which GitHub Actions are allowed to run, and even whether the feature is enabled at all.
Furthermore, each GitHub Action Workflow runs with its own explicit permissions. So, the security capabilities of each Workflow are clearly stated, and less-trusted Actions can be run with lower privilege settings than more-trusted Actions. This type of "least-privilege" access management is a highly effective security strategy, and it's not possible in monolithic and/or legacy CI/CD jobs.
As always, freedom comes with responsibility and we've heard of at least one organization that has locked its developers out of GitHub Actions after incidents of careless, insecure coding. So, be aware and mindful of the security controls that are available, and use them!
How we're using GitHub Actions and AppMap together to improve code quality
AppMap is a tool that records code traces into JSON data files, which can be visualized and analyzed to improve code understanding and quality. GitHub Actions offers a way to create a comprehensive AppMap data set for every pull request, providing a complete profile of the runtime architecture, performance, and security characteristics of your application. It also offers a way to compare the AppMap data sets of two different code versions.
Comparing AppMaps of two code versions (a baseline and a proposed change set) is an amazingly powerful technique for analyzing code for architecture changes, security flaws and performance problems. With AppMap for GitHub Actions, we are offering exactly this capability. Our Early Access program is wrapping up now, and we are transitioning to general availability. Come check it out!
Because AppMap runs in your GitHub account, the data is processed within your account and it stays within the boundaries of it. You don't have to share source code or sensitive data with any third party. This is the type of win/win/win capability that GitHub Actions offers. A high level of developer control, good performance, and good security characteristics.
How are you using GitHub Actions?
Has your organization adopted GitHub Actions? How enabled are developers to add and change GitHub Actions? Did you encounter any problems or mishaps along the way that others could benefit from hearing about? We would love to hear about it in the comments below.
Links
🤖 Get Early Access to AppMap for GitHub Actions: https://getappmap.com
⬇️ Download AppMap for VSCode and JetBrains: https://appmap.io/download
⭐ Star AppMap on GitHub: https://github.com/getappmap
📹 Follow on: https://youtube.com/@appmap
💬 Join AppMap Slack: https://appmap.io/slack
ℹ️ Read the AppMap docs: https://appmap.io/docs
Top comments (0)