My Journey Into GitHub Actions - #1 - Getting Started

A long, long, time ago

When I first starting blogging back in 2004, it was all about Visual Studio Team System. Rather than trying to create fully-formed, detailed walkthroughs and explanations of the technology, I was instead just diving into the product, trying it out and clicking things and seeing what happened.

Through the years my style has changed (and for the past several years, completely stagnated), but I always remember loving that type of exploration and writing. And while things are a lot differnet now, and there is a lot more documentation out there, that kind of exploration still appeals to me. So that’s what I’m going to do with my journey into GitHub Actions.

I’m sure at some point I’ll create some posts specifically around “How To Do X” with GitHub Actions, but the “Journey” posts are going to be more exploratory, full of stuff that works and stuff that doesn’t. Have some feedback for me? Send me a tweet!

What is GitHub Actions?

So what is GitHub Actions? You can start with the documentation to learn details. GitHub Actions allows you to automate, customize, and execute your software development workflows in your repositories. For a majority of people, they think of GitHub Actions as CI/CD (Continuous Integration/Continuous Deployment), and that is a prime use case for it. But it can also execute workflow beyond just your standard CI/CD. Want to know more? Go check out the docs. I’m just gonna dive right in and see what happens.

Creating A New Repo At GitHub

I’ve decided to create a new public repository for all my GitHub Action experiments and learnings. I went to GitHub.com and logged in. In the upper-right of the screen, I can click the “+” button and select New repository.

This opens the Create a new repository page. I’m going to call my repo mickey-learns-actions, and I’m going to make it public. This also means it is open to any of you who would like to follow along. I’m going to add a Visual Studio .gitignore file, as probably most of my coding will be either in Visual Studio or Visual Studio Code. Then I click the big green Create repository button.

This takes me to the main page of my new repo, and opens me up initially to the Code tab. Right now we can see my repo has two files in it: .gitignore and README.md.

Let’s Go Create An Action’s Workflow

It also has this nifty little tab called Actions. Interesting. Let’s see what happens when I click on the Actions tab.

.

This is kinda helpful. It realizes I haven’t set up any Action’s yet, so it suggests a workflow for me, based off whats in my repo. I can also choose to create a workflow from scratch, or I can scroll down and see some of the other workflow templates available to me, such as:

• Node.js to Azure Web App
• Deploy to Amazon ECS
• Rust
• Python
• Ruby (ooooh, my website runs on Jekyll, I might have to check that out)
• and lots more…

At the very bottom you will also see three workflows that are not “build” related, but more process related, showing you some of the power that GitHub Actions gives you besides CI/CD.

For now, I’m just gonna select the Simple Workflow at the top. So I click on the Set up this workflow button. And I get this:

It looks like the GitHub Actions workflow files are going to be stored in .github/Workflows. The initial name of the file is blank.yml, which won’t do, so I’m going to change it to mickeys-first-workflow.yml. The workflow files are YAML-based, and pretty easy to read. If I scan through the file from top to bottom, it appears to be:

• Triggering on a push or a pull request, but only for the master branch.
• Running on Ubuntu Linux
• Checkouts the repository (which makes sense, as it needs the repo to be able to do something with the repo)
• Runs some commands in a shell

Overall, pretty basic and easy to understand. Let’s save our name change and run this and see what happens. In the top right there is a green button, Start commit. Click that button and you get the following window:

For the commit message, I’ll just enter Initial Version, which is my standard first commit message. I’ll also provide an extended description: This is the out of the box version of my workflow. And then click the Commit new file button. Yes, I know I’m committing a cardinal sin by committing straight to master, but its ok right now. Clicking the commit button takes me back here:

Interesting. I thought it might take me to the Actions tab. No worries, I simply click on the Actions tab:

Check Out The Results

Hey hey, it looks like something is happening. Or actually, has already happened. Successfully, I assume, because of the green checkbox. If I click on the description, it takes me to some details of the workflow run:

I had 1 job run, that completed successfully in 17 seconds. Not bad! If I click on the workflow file tab, I can see the YAML code for the workflow that executed.

If I click on the word build on the left hand side (which is the name of the job specified in the YAML file), I can see the logs from the job run:

As I can see in the log, each step from the YAML file is shown, and I can drill into each step to see the detailed logs from that particular step. If I expand the two steps that were running scripts, I see the following:

I can see that both steps wrote out what was expected. This is great, my workflow worked!