README.md

Github Actions

Github actions enable us to create custom software development lifecycle workflows directly into github repositories.With GitHub Actions, you can create custom, automated tasks or "actions" that run in response to events in your GitHub repositories, such as pushes to your code or the creation of a pull request

Github actions are event driven

Events: When something happens in or to your repository.eg. Push,pull request etc.

Actions

• This are scripts that run in response to specific events in repositories.
• This are helpful for running common tasks in repeatable manner without writing it again and again.
• Actions perform specific tasks like checking the code,building your code,publishing packages etc.
• There are large number of actions created by community that we can use and we can also create our own custom actions.

Workflows

• Orchestration of all the jobs that will occur in our action.
• Workflow consist of number of actions that occur in a particular order.
• Workflow can be triggered after an event occur in Github.
• A bunch of actions together is called a Job.
• A bunch of Job is called a Workflow.
• A Repository can contain multiple workflows.
• This are stored in the .github/workflow directory.

A workflow consists of:

1.name

• It defines the name of the workflow
• It is an optional attribute.

2.on

• It defines the Github event that triggers the workflow,which may be:

  • Repository events

    • push
    • pull_request
    • release

  • Webhooks

    • Branch creation
    • issues
    • members

  • Scheduled

    • Cron format

  • Manually triggered

    • Workflow_dispatch(Third party like API's)

• It is a required attribute.

3. job

• It is a block that defines the jobs for the workflow
• Each workflow must have atleast one job.
• Each job must have an identifier which must start with a letter or underscore
• jobs run in parallel by default.

4. runs-on

• It lets github know the type of machine we would like to use to run the job.
• It defines the OS environments called runners where the job will run.
• Each job can run different runner.

5. steps

• List of actions or commands

• steps are tasks within a job

• Access to the file system

• Each step runs on its own process.

• steps consist of

  1. uses

     • identifies an action to use - The could be located in public repository,same repository as the workflow or a docker image registry.
     • Define the location of that action.

  2. run

     • runs commands in the virtual environment's shell

  3. name

     • an optional identifier of the step.

A simple workflow

name: first

on: push

jobs:
  job1:
      name: First job
      runs-on: ubuntu-latest
      steps:
      - name: Step one
        uses: actions/checkout@v2
      - name: Step two
        run: env | sort
  job2:
      name: Second job
      runs-on: windows-latest
      steps:
      - name: Step one
        uses: actions/checkout@v2
      - name: Step two
        run: "Get-ChildItem Env: | Sort-Object Name"
    

A workflow in GitHub Actions consists of several components, including:

Triggers: These are the events that initiate a workflow, such as a push to your code, the creation of a pull request, the opening of an issue, and more.

Actions: Actions are individual scripts that perform specific tasks as part of your workflow. They can be shared by the community or created by you.

Jobs: Jobs are a sequence of steps that run within a workflow. Jobs can run in parallel or sequentially, depending on your needs.

Steps: Steps are individual commands or actions within a job. They run in the order specified and can run actions, set environment variables, and more.

Workflow files: Workflow files are YAML files stored in your GitHub repository that define your workflows. They specify the triggers, jobs, and steps that make up your workflow, as well as any environment variables or secrets that your workflow needs to access.

Artifacts: Artifacts are files or data generated by a workflow that can be passed between steps or jobs within the same workflow, or between workflows.

Runs: Runs are instances of a workflow that are triggered by an event and run on the GitHub Actions workflow runner. Each run is tracked and can be viewed in the GitHub Actions interface.

Adding dependencies

we can use need attribute to add the dependencies between the jobs

needs:Identifies one or more jobs that must complete successfully before a job will run.

jobs:
   job1:
   job2:
   job3:
      needs: [job1,job2]

In the example above job 3 depends on job1 and job2 to run successfully.

Conditionals

This are used to specify the tasks based on the condition For this we need to create a new block

Using the actions from the Github marketplace

• The actions in the GitHub Marketplace are pre-built scripts that can be used to automate a wide range of tasks, from building and testing code, to deploying applications, to managing your workflows and projects.

Using the actions from a Repository

• Actions can be used from workflow's repo

steps:
     - uses: "./github/action1"

• From any public repository

steps:
     - uses: "user/repo@ref"

• Docker images from an image registry
• Specify the "docker://" path to the image and tag
• Docker hub is used by default

steps:
     -uses: "docker://image:tag"

Passing arguments to an action

• steps use the with attribute to pass argument
• With creates a new block for mapping arguments to inputs

syntax:

steps:
     - name: Checkout the code
     uses: actions/checkout@v3
     with:
          key:value
          key:value
          

Passing environment variables

• Environment variables are dynamic key value pair stored in the memory.
• Environment variables are not already stored in the memory rather they are injected when the process starts
• This are case sensitive
• We can define our own environment variables in env attribute.
• The env can be defined in the workflow,jobs or steps level.

Scope of the variables

1. If the variables are declared at the workflow level they can be accessed by all jobs,steps,all actions and all commands.
2. If the variables are declared at the jobs level they can be accessed by all steps,all actions and commands within the job.
3. If the variables are declared at the steps level they can be accessed by all the step.

Accessing the env variables

The variable can be accessed by two ways:

• Shell variable syntax

  1. Bash (Linux/macOS) - `$VARIABLE_NAME`      
  2. Powershell (Windows) - `$Env:VARIABLE_NAME` 
  

• YAML syntax - - ${{ env.VARIABLE_NAME }}

example:

name: Environment Variables
env:
    MY_ENVIRONMENT_VARIABLE: 'Hello there :)'
    
on: [push]
jobs:
    first-job:
          runs-on: ubuntu-latest
          steps:
            - name: Print env variable
              run: | 
                 echo "$MY_ENVIRONMENT_VARIABLE"

Using secrets in the workflow

Sometimes we need to store passwords,API keys etc in the workflows

• Secrets are stored in the github repository settings.
• Can't be viewed or edited once created
• Workflows can have up to 100 secrets
• Secrets limited to 64 KB

• Once the secrets are created they can't be seen or modified.

To access the secret

${{ secrets.SECRET_NAME }}

Secrets can be passed as env variables or parameters

example

name: My Workflow

on: push

env:
  MY_SECRET_VAR: ${{ secrets.MY_SECRET_VAR }}

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Print the secret
      run: echo "The secret is: ${MY_SECRET_VAR}"

Artifacts

• Artifacts are data preserved from a workflow.
• They may be files or collection of files like archieves,log files

Artifacts can be used to pass data between workflows jobs.

For example suppose there are two jobs where second job needs a file which is created by first job.

Job 1 - Creates and upload artifact Job 2 - Wait for the Job 1 to complete and then download and use the artifact

• Artifacts can only be uploaded by a workflow using actions/upload-artifact

• And can only be downloaded by the uploading workflow using actions/download-artifact

• Artifacts are by default stored for 90 days.

example:

name: Artifact

on: [push]

env:
   ARTIFACT_NAME: myartifact
   
jobs:
   main:
      runs-on: ubuntu-latest
      steps:
         - name: checkout the code
           uses: actions/checkout@v2
         - name: upload the artifact
           uses: actions/upload-artifact@v2
           with:
               name: ${{ env.ARTIFACT_NAME }}
               path: .
               

Managing PR's using the github actions

Github actions can be use to

• Automatically approve and merge the PR's based on criteria
• Run automated tests to check the code in the PR
• Check the username that submitted the PR
• Approve and merge the PR
• Delete the branch associated with the PR

Matrix strategy

Using matrix strategy we can make one job to create a variety of different configuration.

jobs:
   build:
     strategy:
         matrix: 
            version: [15,16,10]
            platform: [ubuntu-latest,windows-latest,windows-latest]
     runs-on: ${{ matrix.platform }}
     steps:
       - uses: actions/setup-node@v2
         with:
            node-version: ${{ matrix.version }}

• We can use the word include and exclude
• we can use include to set additional values

jobs:
   build:
     strategy:
         matrix: 
            version: [15,16,10]
            platform: [ubuntu-latest,windows-latest,windows-latest]
            include:
             - platform: ubuntu-latest
               version: 18
               

• Exclude can be used to remove values from the combination.

jobs:
   build:
     strategy:
         matrix: 
            version: [15,16,10]
            platform: [ubuntu-latest,windows-latest,windows-latest]
            exclude:
             - platform: windows-latest
               version: 18

• Includes are processed after excludes
• fail-fast enables to remove job if even one job fails
• Default value is true,but can be configured to false

strategy:
    fail-fast: false
    matrix:
        version: [2,3,6]
        platform: [ubuntu-latest,windows-latest]
        experimental: [ false]
    include:
       - platform: ubuntu-latest
         version: 15
         experimental: true
    continue-on-error: ${{matrix.experimental}}

• A maximum of 256 jobs can be created per workflow.we can set the limit using max-parallel: 4

Self Hosted Runners

Runners are servers consisting of Hardware,operating Systems,programs etc. that run jobs in a workflow.Github provides hosted runners that are already present in github.com.

Self Hosted Runners are type of runners in GitHub actions that we can create and manage on our own infrstructure which may be a virtual machine,a physical server or a container.

Self Hosted Runners allow us to customize our runners according to our own need,we can install dependencies and tools according to our specific needs.