Get a Jump Into GitHub Actions
This article outlines the highlights of a recent webinar that Angie Jones of Applitools hosted, featuring Brian Douglas, a Staff Developer Advocate at GitHub.
Join the DZone community and get the full member experience.Join For Free
On January 27, 2021, Angie Jones of Applitools hosted Brian Douglas, aka "bdougie", a Staff Developer Advocate at GitHub, for a webinar to help you jump into GitHub Actions. You can watch the entire webinar on YouTube. This article goes through the highlights for you.
Angie Jones serves as Senior Director of Test Automation University and as Principal Developer Advocate at Applitools. She tweets at @techgirl1908, and her website here.
Brian Douglas serves as the Staff Developer Advocate at GitHub. Insiders know him as the "Beyoncé of GitHub." He blogs here and tweets as @bdougieYO.
They ran their webinar as a question-and-answer session. In the subsections below are some of the key ideas covered.
What Are GitHub Actions?
Angie's first question asked Brian to jump into GitHub Actions.
Brian explained that GitHub Actions is a feature you can use to automate actions in GitHub. GitHub Actions let you code event-driven automation inside GitHub. You build monitors for events and, when those events occur, they trigger workflows.
If you're already storing your code in GitHub, you can use GitHub Actions to automate anything you can access via webhook from GitHub. As a result, you can build and manage all the processes that matter to your code without leaving GitHub.
Build Test Deploy
Next, Angie asked about Build, Test, and Deploy, as it is what she hears about most frequently when she hears about GitHub Actions.
Brian mentioned that the term, GitOps, describes the idea that a push to GitHub drives some kind of activity. A user adding a file should initiate other actions based on that file. External software vendors have built their own hooks to drive things like continuous integration with GitHub. GitHub Actions simplifies these integrations by using native code now built into GitHub.com.
Get Back to What You Like to Do
Angie pointed out that this catchphrase, "Get back to what you like to do," caught her attention. She spends lots of time in meetings and doing other tasks when she'd really just like to be coding. So, she asked Brian, how does that work?
Brian explained that, as teams grow, so much more of the work becomes coordination and orchestration. Leaders have to answer questions like the following:
- What should happen during a pull request?
- How do we automate testing?
- How do we manage our build processes?
When engineers have to answer these questions with external products and processes, they stop coding. With GitHub Actions, Brian said, you can code your own workflow controls. You can ensure consistency by coding the actions yourself. And, by using GitHub Actions, you make the processes transparent for everyone on the team.
Do you want a process to call Applitools? That's easy to set up.
Brian explained that GitHub hosted a GitHub Actions Hackathon in late 2020. The team coded the controls for the submission process into the hackathon. You can still check it out here.
The entire submission process got automated to check for all the proper files being included in a submission. The code recognized completed submissions on the hackathon home page automatically.
Brian then gave the example of work he did on the GitHub Hacktoberfest in October. For the team working on the code, Brian developed a custom workflow that allowed any authenticated individual to sign up to address issues exposed in the Hackathon. Brian's code latched onto existing authentication code to validate that individuals could participate in the process and assigned their identity to the issue. As the developer, Brain built the workflow for these tasks using GitHub Actions.
What can you automate? Informing your team when a user does a pull request. Send a tweet when the team releases a build. Any webhook in GitHub you can automate with GitHub Actions. For example, you can even automate the nag emails that get sent out when a pull request review does not complete within a specified time.
Angie then asked about the most common actions that Brian sees users running.
Brian summarized by saying, basically, continuous integration (CI). The most common use is ensuring that tests get run against code as it gets checked in to ensure that test suites get applied. You can have tests run when you push code to a branch, push code to a release branch or do a release, or even when you do a pull request.
While test execution gets run most frequently, there are plenty of tasks that one can automate. Brian did something specific to assign gifts to team members who reviewed pull requests. He also used a cron job to automate a GitHub Action which opened up a global team issue each Sunday US, which happens to be Monday in Australia, and assigned all the team members to this issue. Each member needed to explain what they were working on. This way, the globally-distributed team could stay on top of their work together without a meeting that would occur at an awkward time for at least one group of team members.
Brian talked about people coming up with true use cases, such as someone linking IoT devices to webhooks in existing APIs using GitHub Actions.
But, the cool part of these actions is that most of them are open source and searchable. Anyone can inspect actions and, if they don't like them, modify them. If a repo includes GitHub Actions, they're searchable.
On this blog, you can see existing workflows that Brian has already put together.
Jump Into GitHub Actions: What Next?
I shared some of the basic ideas in Brian's conversation with Angie. If you want to jump into GitHub Actions in more detail, you can check out the full webinar and the slides in Addie Ben Yehuda's summary blog for the webinar. That blog also includes a number of Brian's links, several of which I include here as well:
Enjoy jumping into GitHub Actions!
Published at DZone with permission of Michael Battat. See the original article here.
Opinions expressed by DZone contributors are their own.