GitHub

GitHub is a cloud platform that uses Git as its core technology. It simplifies the process of collaborating on projects and provides a website, command-line tools, and overall flow that allows developers and users to work together. GitHub acts as the "remote repository"

Forking a Repository - Forking a repository makes a copy of the repository in your GitHub account. The parent repository is referred to as the upstream while your forked copy is referred to as the origin.

GitHub Actions

GitHub actions provide task automation and workflow functionality in a repository. Actions can be used to streamline processes in your software development lifecycle and implement continuous integration and continuous deployment (CI/CD).

GitHub Actions are composed of the following components:

• Workflows: Automated processes added to your repository.

• Events: An activity that triggers a workflow.

• Jobs: A set of steps that execute on a runner.

• Steps: A task that can run one or more commands (actions).

• Actions: Standalone commands that can be combined into steps. Multiple steps can be combined to create a job.

• Runners: Server that has the GitHub Actions runner application installed.

Two types of GitHub actions

There are two types of GitHub actions: container actions and JavaScript actions.

With container actions, the environment is part of the action's code. These actions can only be run in a Linux environment that GitHub hosts. Container actions support many different languages.

JavaScript actions don't include the environment in the code. This means you'll have to specify the environment to execute these actions. You can run in a VM in the cloud or on-premises. JavaScript actions support Linux, macOS and Windows environments.

The components of GitHub Actions

Continuous Integration (CI)

CI is the practice of using automation to build and test software every time a developer commits changes to version control.

In addition to default environment variables, you can use defined variables as contexts. Contexts and default variables are similar in that they both provide access to environment information, but they have some important differences. While default environment variables can only be used within the runner, context variables can be used at any point within the workflow. For example, context variables enable you to run an if statement to evaluate an expression before the runner is executed.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

This example is using the github.ref context to check the branch that triggered the workflow. If the branch is main, the runner is executed and prints out "Deploying to production server on branch $GITHUB_REF". The default environment variable $GITHUB_REF is used in the runner to refer to the branch.

Notice that default environment variables are all uppercase where context variables are all lowercase.

Custom Environment Variables

Similar to using default environment variables, you can use custom environment variables in your workflow file. To create a custom variable, you need to define it in your workflow file using the env context. If you want to use the value of an environment variable inside a runner, you can use the runner operating system's normal method for reading environment variables.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

Scripts in your workflow

In the above workflow snippet examples, the run keyword is used to simply print a string of text. Since the run keyword tells the job to execute a command on the runner, you use the run keyword to run actions or scripts.

jobs:
  example-job:
    steps:
      - run: npm install -g bats

In this example, you are using npm to install the bats software testing package by using the run keyword. You can also run a script as an action. You can store the script in your repository, often done in a .github/scripts/ directory, and then supply the path and shell type using the run keyword.

jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash