{"id":277728,"date":"2018-10-17T10:26:22","date_gmt":"2018-10-17T17:26:22","guid":{"rendered":"http:\/\/css-tricks.com\/?p=277728"},"modified":"2018-10-20T18:25:16","modified_gmt":"2018-10-21T01:25:16","slug":"introducing-github-actions","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/introducing-github-actions\/","title":{"rendered":"Introducing GitHub Actions"},"content":{"rendered":"

It\u2019s a common situation: you create a site and it\u2019s ready to go. It\u2019s all on GitHub. But you\u2019re not really done<\/em>. You need to set up deployment. You need to set up a process that runs your tests for you and you’re not manually running commands all the time. Ideally, every time you push to master, everything runs for you: the tests, the deployment… all in one place.<\/p>\n

Previously, there were only few options here that could help with that. You could piece together other services, set them up, and integrate them with GitHub. You could also write post-commit hooks, which also help.<\/p>\n

But now, enter GitHub Actions<\/a>.<\/strong><\/p>\n

<\/p>\n

\"\"<\/figure>\n

Actions are small bits of code that can be run off of various GitHub events, the most common of which is pushing to master. But it’s not necessarily limited to that. They\u2019re all directly integrated with GitHub, meaning you no longer need a middleware service or have to write a solution yourself. And they already have many options for you to choose from. For example, you can publish straight to npm and deploy to a variety of cloud services, (Azure, AWS, Google Cloud, Zeit… you name it) just to name a couple.<\/p>\n

But actions are more than deploy and publish.<\/em> That\u2019s what\u2019s so cool about them. They\u2019re containers all the way down, so you could quite literally do pretty much anything<\/em> — the possibilities are endless! You could use them to minify and concatenate CSS and JavaScript, send you information when people create issues in your repo, and more… the sky’s the limit.<\/p>\n

You also don\u2019t need to configure\/create the containers yourself, either. Actions let you point to someone else\u2019s repo, an existing Dockerfile, or a path, and the action will behave accordingly. This is a whole new can of worms for open source possibilities, and ecosystems.<\/p>\n

Setting up your first action<\/h3>\n

There are two ways you can set up an action: through the workflow GUI<\/abbr> or by writing and committing the file by hand. We\u2019ll start with the GUI because it\u2019s so easy to understand, then move on to writing it by hand because that offers the most control.<\/p>\n

First, we\u2019ll sign up for the beta by clicking on the big blue button here<\/a>. It might take a little bit for them to bring you into the beta, so hang tight.<\/p>\n

\"A
The GitHub Actions beta site.<\/figcaption><\/figure>\n

Now let\u2019s create a repo. I made a small demo repo<\/a> with a tiny Node.js sample site. I can already notice that I have a new tab on my repo, called Actions:<\/p>\n

\"A<\/figure>\n

If I click on the Actions tab, this screen shows:<\/p>\n

\"screen<\/figure>\n

I click “Create a New Workflow,” and then I\u2019m shown the screen below. This tells me a few things. First, I\u2019m creating a hidden folder called .github<\/code>, and within it, I\u2019m creating a file called main.workflow<\/code>. If you were to create a workflow from scratch (which we\u2019ll get into), you\u2019d need to do the same.<\/p>\n

\"new<\/figure>\n

Now, we see in this GUI that we\u2019re kicking off a new workflow. If we draw a line from this to our first action, a sidebar comes up with a ton of options.<\/p>\n

\"show<\/figure>\n

There are actions in here for npm, Filters, Google Cloud, Azure, Zeit, AWS, Docker Tags, Docker Registry, and Heroku. As mentioned earlier, you\u2019re not limited to these options — it’s capable of so much more!<\/p>\n

I work for Azure, so I\u2019ll use that as an example, but each action provides you with the same options, which we’ll walk through together.<\/p>\n

\"shows<\/figure>\n

At the top where you see the heading “GitHub Action for Azure,” there\u2019s a “View source” link. That will take you directly to the repo that’s used<\/a> to run this action. This is really nice because you can also submit a pull request to improve any of these, and have the flexibility to change what action you\u2019re using if you\u2019d like, with the “uses” option in the Actions panel.<\/p>\n

Here’s a rundown of the options we’re provided:<\/p>\n