Github Actions 101 and the Checkout Action
Github Actions 101 and the Checkout Action
Choosing a continuos integration tool if you are an undecided person is never easy, there are alot options and lots of strong cases, so I totally get if you are currently looking and still haven’t made up your mind. On this post I will talk a bit about my encounter with Github Actions and I will also provide a very small use case example. Not sure if this can help anyone to decide but come along, it’s going to be fun (😬).
I first used Github Actions on my previous job. We didn’t have a CI structure so we thought that it would be nice to have one, we were doing alot of automation and that felt like the natural thing to do. Back then I did some research and listed some candidates for the CI tools. We first tried to use Jenkins for a while but the amount of setup didn’t make sense for us and we never quite got it to work properly. It’s known that Jenkins is really good and can do alot, but we had a small team and system and I felt like the time that I put on learning Jenkins was not paying off fast enough. So I started studying about Github Actions (GHA), and felt pretty fresh. I believe that GHA was in it’s early days and even though they provided some tutorials and tips it was still a bit complicated to put it to work with our system… nothing compared with Jenkins though.
 |
| Geez, I did this meme 2 years ago, and I am sorry |
The first thing you need to do is to give your workflow a name. After that we can define the moment where this workflow will run. Back in my previous work we used to have one for PRs and another for pushes. On this example we are going to go for a simple but common use case: PRs that involve master. We can see the beginning of the workflow below:
name: Workflow that run on master PRs..
on:
pull_request:
branches: - masterWhat these instructions says basically, is that whenever a PR envolving master is created or changes to it are made, we will be running the instructions defined on the .yaml file. Then, what we need to do is to create the jobs, set the steps and define where the instructions will be running.
jobs:
build:
runs-on: ubuntu-latest
We can see that on the line with the runs-on key, we choose ubuntu-latest, and that does exactly what it looks like. We are choosing to run this workflow on an ubuntu machine. GHA allows us to choose different OSs for our workflows (that include windows and macOS).
After that, on this example we choose to start with our steps. Inside the steps we will be defining what our workflow will do. GHA offers a set of pre-made actions that can help us skip some boring work, per example, instead of manually setting node.js through the terminal we can create a workflow that comes with it from the start, saving us some headache and making our workflows look prettier 💅. Many other actions exists and they can be used for the most diverse objectives. So, without further adue let’s summon the checkout action in our example workflow. This action will allow us to checkout repositories and that can be very useful and save us some commands. We expand the checkout example below:
- name: Checking out this very cool repository using on the master branch
run: echo 'I am just echoing here because I can'
- uses: actions/checkout@v2
with:
name: nameOfTheRepo
repository: <nameOfTheOrgOrUser>/<nameOfTheRepo>
ref: origin/master
We need a name of the repo and then on the repository key we need to insert the data following the <owner>/<repoName> pattern.
On the ref key what we will to do is to set the branch of the repository that is being checked out. We can use any valid branch to do it, on the example above we went with origin/master. The run key let us execute terminal commands, we can use it as we would on our personal machines.
Another thing is that if you are checking out a private repository you will need a token to do so. Let’s say we are going to need multiple services to test a system and each service is located in a separated repository, we will need to generate a token to clone these repositories in the workflow machine (this link can help on the token generation part: https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token).
After getting the token, the thing to do is to save it as a secret. We can save secrets by first going into the repository settings, and clicking on secrets. Then, you will see the input fields for a new secret:
 |
We can use secrets for anything basically, per example, when I first started with GHA, I would use secrets to store our .env data, even though there are other ways to do that.
Continuing with our example, now if we wanted we can checkout our second repository, simple as that.
- name: Checking out this cool repo from master branch
run: echo 'checking another repo'
- uses: actions/checkout@v2
with:
name: nameOfTheRepo2
repository: <anotherOwner>/<nameOfTheRepo2>
ref: origin/master
token: ${{secrets.clone_token}}
It’s important to remember that we are on a machine with terminal access and we can use regular commands if we need to, we can walk through directories, delete things, download stuff and all the rest. Some very useful programs like docker come with the workflows by default as well, so we can just use it .
Let’s consider that after checking out our repositories we get into a point where we can, with docker, start our environment then run our tests. So what we will need to do is to set a new step, give it a name and choose what to run inside it. In the example below we go to the correct directory and build the docker image, then on the Running tests step, all that we do is run the test command.
- name: Creating Env phase
run: cd work/<primaryRepo> && docker-compose build <primaryRepo> && docker-compose up -d- name: Running tests
run: cd work/<primaryRepo> && docker exec <primaryRepo> yarn testThe final .yaml would look like:
name: Workflow that run on master PRs..
on:
pull_request:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Kicking things off
run: echo 'Kicking things off' - name: Checking out this very cool repository using on the master branch
run: echo 'I am just echoing here because I can'
- uses: actions/checkout@v2
with:
name: nameOfTheRepo
repository: <nameOfTheOrgOrUser>/<nameOfTheRepo>
ref: origin/master - name: Checking out this other cool repo from master branch
run: echo 'I am just echoing here because I can'
- uses: actions/checkout@v2
with:
name: nameOfTheRepo2
repository: <anotherOwner>/<nameOfTheRepo2>
ref: origin/master
token: ${{secrets.clone_token}} - name: Creating Env phase
run: cd work/<primaryRepo> && docker-compose build <primaryRepo> && docker-compose up -d - name: Running tests
run: cd work/<primaryRepo> && docker exec <primaryRepo> yarn test
continue-on-error: false  |
Aaand, that’s Github Actions 101-0.
We presented on this post a small example of GHA usage and without a doubt there are alot other things to do with it. We showed here a simple use case and hopefully in the future we will be able to discuss and bring more pratical usage of this tool to this blog. To expand on what it was discussed here, I highly encourage anyone that read this post to dive deeper into the documentation and on the example repository. Plenty of useful and interesting stuff 😉!
PS: Edit texts on blogger it's too hard.
Comentários
Postar um comentário