You are currently viewing GitHub Actions Workflow Part 3 – Jobs

GitHub Actions Workflow Part 3 – Jobs

GitHub Actions Workflow Part 3 – Jobs

Hello Everyone

Welcome to CloudAffaire and this is Debjeet.

In today’s blog post, we will discuss jobs workflow element in GitHub. A job is an intent of single or multiple actions that you want to perform in your GitHub workflow. A job comprises of mainly a job name and id to uniquely identify each job in the GitHub workflow, target (runs_on) where the job will get executed and actions (steps) that the job needs to carry out.

Jobs id (required) and name (optional): Each job must have an id in the form of a string that uniquely identify the job in the workflow. You can also assign a name to your job that gets displayed in GitHub.

Jobs needs (optional): You can create dependency of one job to another using needs workflow element. If the job defined in needs failed then the parent job doesn’t get executed. You can override this with always() that ensures even if the dependent job is failed the parent job always gets executed.

Jobs runs-on (required): You can define the target system known as GitHub runner where the job will get executed using runs-on workflow element. You can use a self-hosted (dedicated) or GitHub-hosted (shared) runner to execute your jobs. Below is the list of GitHub-hosted runner that you can use currently.

  • windows-2022: Windows Server 2022[beta]
  • windows-latest or windows-2019: Windows Server 2019
  • windows-2016: Windows Server 2016
  • ubuntu-latest or ubuntu-20.04: Ubuntu 20.04
  • ubuntu-18.04: Ubuntu 18.04
  • macos-11: macOS Big Sur 11
  • macos-latest or macos-10.15: macOS Catalina 10.15

If you are using a self-hosted runner, you need to provide the self-hosted label along with other custom labels as an array to runs-on workflow element.

Jobs outputs (optional): A map of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. Job outputs are strings, and job outputs containing expressions are evaluated on the runner at the end of each job. Outputs containing secrets are redacted on the runner and not sent to GitHub Actions.

Jobs if (optional): You can use if condition inside a job to execute the job based on some condition evaluation.

Jobs timeout-minutes (optional): The maximum number of minutes to let a job run before GitHub automatically cancels it, default: 360. If the timeout exceeds the job execution time limit for the runner, the job will be canceled when the execution time limit is met instead.

Jobs continue-on-error (optional): Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.

Jobs strategy (optional): You can use strategy to create a build matrix to run different variations of a job from a single definition.

  • Jobs strategy matrix (optional): You can define a matrix of different job configurations. A matrix allows you to create multiple jobs by performing variable substitution in a single job definition.
  • Jobs strategy fail-fast (optional): When set to true, GitHub cancels all in-progress jobs if any matrix job fails. Default: true
  • Jobs strategy max-parallel (optional): The maximum number of jobs that can run simultaneously when using a matrix job strategy.

Jobs uses (optional): The location and version of a reusable workflow file to run as a job. {owner}/{repo}/{path}/{filename}@{ref} where {ref} can be a SHA, a release tag, or a branch name.

Jobs with (optional): When a job is used to call a reusable workflow, you can use with to provide a map of inputs that are passed to the called workflow. Any inputs that you pass must match the input specifications defined in the called workflow.

Jobs secrets (optional): If you have stored any secret like passwords or api keys in your repository and want to access and use the secret in your workflow, use secrets element of GitHub workflow.

Hope you have enjoyed this article. To know more about GitHub, please refer below official documentation

Leave a Reply