Automating Software Development Workflows with Github Actions 🚀 | by Ansh Sachdeva

1. name: Denotes the name of the GitHub action that will show up in the action run history
2. on : This section denotes the events that will trigger the jobs defined in the job section. there can be many sub configurations in this block. For eg, if we want the workflow to get triggered by a pull request, we can mention the names of branches against which the PR should be made to trigger. another sub-config available for PR is type: which can take the values of closed, opened, edited, .. etc. The complete list of events can be found here
3. jobs: This section consists of various jobs that will be executed in parallel once the event(s) mentioned in on section occur. their name can be anything:

jobs:
   lint-static_checks-test-build:
    <config>
   parallel_job_2:
    <config>
   parallel_job_3:
    <config>
...

3.1 Setting up a job.

A job could consist of many attributes for a specific configuration. An example of some of the common attributes would look like these:

jobs:
  my_first_job:
    permissions:
contents: read
packages: write
 runs-on: [self-hosted, ubuntu-latest]
    steps:
         ...
  job2:
    if: $  <expression> 
needs: my_first_job

1. permissions: These are the container-level permissions that we are providing to our job. There can be multiple types of permissions.
2. runs-on: here we are defining the machine that will be used to execute the job
3. if: $}: These are conditional expressions that are executed in a declarative manner. the conditions can be applied to various levels in a workflow. it can be used to skip or perform the whole job or just a step. But what do these conditions work upon? the $ can be used to evaluate any condition like $1+2==3 . There are also certain properties that get generated for every step or job like $job.status == 'success'. These are called context.
4. needs: This is an attribute that makes different parallel running jobs run sequentially. ideally, job2 in the first example should be running in parallel to my_first_job. by using needs, we are making sure that job2 will run after my_first_job
5. steps: A job contains a sequence of tasks called steps. Steps can run commands, run set up tasks, or run actions in your repository, a public repository, or action published in a Docker registry. Steps can take inputs (in the form of constants) and generate output. The steps in a job are executed sequentially. By default, the steps are configured to fail execution if the previous step has failed or given a failure output, but this behaviour could be modified via conditional expressions.

3.2 Structure of a step

steps:   
    - name: Setup Path Filter task and Execute
      uses: dorny/paths-filter@v2
id: filter
with:
filters: |
md: ['CHANGELOG.md']   - name: FAIL if mandatory files are not changed
if: $ steps.filter.outputs.md == 'false' 
uses: actions/github-script@v3
with:
script: |
core.setFailed('Mandatory markdown files were not changed')    - name: Generate AAR and APK files.
shell: bash
run: ./gradlew assembleDebug

1. name: This is an optional key that gives a small description of the step. if the name key is present, then it will show up in the workflow terminal during execution
2. id: This is another optional key that uniquely identifies the step. we can get details about the step(its inputs, outputs, execution time, etc) using this key. here the 2nd step “FAIL if mandatory files are not changed” uses the input of its previous step to determine whether to run or fail the action via steps.filter.* syntax
3. uses and run: These are 2 very important features of a step. a step must define either one of these.
4. when using uses, we are letting the runner know that we want to execute a bunch of commands that are written in some action from the marketplace. It’s like using a library. for eg dorny/paths-filter is a popular activity for checking whether some file has changed or not
5. When using run, we are letting the runner know that we want to execute a particular command on the host machine. this is like using a terminal in our own machine: whether the command can execute successfully or not depends upon the already present software on the system and whether it would support its execution. For eg : ./gradlew assembleDebug is a terminal command that we want to run, and it will only execute successfully if the host machine has gradle installed by default, or as a part of the previous sequential steps
6. shell: This command is used in association with run command to let the host machine know about the terminal we want to use
7. with: This attribute is used with steps that use 3rd party actions (via uses )only and provides inputs to them. you can pass numbers, strings, or even js scripts via arguments in the with block. The keys are defined by those actions themselves
8. env: This attribute is similar to with, but is used to define inputs for the step itself, and can be used with both uses and run

if we have to create 10 more workflows that use Check lint and Upload Lint results, it would require us to copy all those long Gradle commands and path names manually which are error-prone. It would also be difficult to maintain 10 such copies for future modifications.

With composition, this file becomes as small as this: