Using GitHub Actions - Part 1

A Step-by-Step Guide to How I Built a Workflow in a GitHub Repository using GitHub Actions.

Lab Scenario:

The goal of this lab was to create an empty workflow file and add events and a job runner. The workflow will not be finished until the next lab, Using GitHub Actions - Part 2. It was important to complete this lab entirely before starting part 2.

Learning Objectives:

After completing this lab, I was able to:

• Create a GitHub workflow to run your Continuous Integration (CI) pipeline
• Add events to trigger the workflow
• Add a job to the workflow
• Add a job runner to the job
• Add a container to the job runner

Prerequisites:

The following was needed to complete the exercises in this lab:

• A basic understanding of YAML (commonly used for configuration files)
• A GitHub account
• An intermediate-level knowledge of Command Line Interfaces (CLIs)
• Since I did not already have a generated personal access token, I had to navigate to GitHub Settings of my account to complete this process (not included in this lab breakdown).

Now that I knew the scenario, lab objectives, and prerequisites, it was time to begin!

Task 1: Fork and Clone the Lab Repository

Steps:

1. Authenticated with GitHub: Ran the sudo apt update, sudo apt install gh, and gh auth login to authenticate to install the GitHub CLI and to authenticate with GitHub in the terminal. This is where the GitHub personal access token was needed.
2. Fork and Cloned the Reference Repository: Ran the gh repo fork ibm-developer-skills-network/wtecc-CICD_PracticeCode --clone=true to fork and clone the reference repository for the lab. A fork is a new repository that shares the code and visibility setting with the original "upstream" repository. They are often used to iterate on ideas or changes before they are proposed back to the upstream repository. In order to create a local copy of a repository on your computer, you clone the repository.
3. Changed to the Lab Folder: After I cloned the repository, I changed to the directory of the lab code and files, wtecc-CICD_PracticeCode using the cd command.

Note: As you can see in the screenshot above, the command to clone the repository was unsuccessful for me when copying the command from the lab instructions so I had to use the GitHub CLI command provided in the GitHub browser and it worked!!

Task 2: Create a Workflow, Add Event Triggers, Add a Job, and Target Python 3.9

Step 1: Create a Workflow

1. Created a workflow yaml file. The first line in the file defined the name of the workflow that shows up in the GitHub Actions page of my repository.
2. Created the directory structure .github/workflows and created a file called workflow.yml. Every workflow starts with a name. The name will be displayed on the Actions page and on any badges. I gave my workflow the name CI workflow by adding a name: tag as the first line in the file.

Step 2: Add Event Triggers

Event triggers define which events can cause the workflow to run. I used the on: tag to add the following events: run the workflow on every push to the main branch, run the workflow whenever a pull request is created to the main branch. The steps are below:

1. Added the on: keyword to the workflow at the same level of indentation as the name:
2. Added push: event as the first event that can trigger the workflow. This is added as the child element of on: so it must be indented under it
3. Added the "main" branch to the push event. This is so the workflow will start every time someone pushes to the main branch, also including merge events. This is done by using the branches: keyword followed by a list of branches.
4. Added a pull request: event similar to the push event. This should be triggered whenever a user makes a pull request on the main branch

Step 3: Add a Job

Now I added a job called build to the workflow file. This particular job will run on the the ubuntu-latest runner. A job is a collection of steps that are run on the events that I provided in the previous steps.

1. Added the jobs: section to the workflow at the same level of indentation as the name.
2. Next, I named the job build: by adding a new line under the jobs: section.
3. Finally, I told GitHub Actions to use the ubuntu-latest runner for the job by using the runs-on: keyword.

Step 4: Target Python 3.9

It's important to consistently use the same version of dependencies and operation systems for all phases of development, including the CI pipeline. Since this lab was developed on Python 3.9, I had to ensure that the CI pipeline also ran on the same version of Python. This was accomplished by running the workflow in a container inside the GitHub Action.

1. Added a container: section under the runs-on: section of the build job and told GitHub Actions to use python:3.9.slim as the image.

Task 5: Saving My Work

Arguably one of the most important tasks was to save my work!

1. Configured the Git account with my email and name using the git config --global user.email and git config --global user.name commands.
2. Staged all my changes I made in the previous steps and pushed them to my forked repository on GitHub using git add -A, git commit - m "Created a workflow", and git push.

Note: Git Add prepares the content staged for the next commit. Git commit -m captures a snapshot of the currently staged changes and the -m allows us to enter the commit message prior to the prompt. Lastly, git push loads the local repository content to the remote repository.

Conclusion:

I successfully completed Part 1 of this lab although the GitHub Action was triggered and has failed that is because the workflow is not finished. I will add the remaining steps in Part 2 of the lab so the workflow runs successfully.

Thanks for reading and I look forward to completing Part 2 of this lab and sharing it.