DefaultJob0.0.6
- Known subtypes:
- Known usages:
- All versions:
Properties(show inherited)
-
-
expand_morelink
A conditional to prevent a job from running unless a condition is met.
You can use any supported context and expression to create a conditional. For more information on which contexts are supported in this key, see Contexts reference.
-
expand_morelink
Identify any jobs that must complete successfully before this job will run.
It can be a string or array of strings. If a job fails or is skipped, all jobs that need it are skipped unless the jobs use a conditional expression that causes the job to continue. If a run contains a series of jobs that need each other, a failure or skip applies to all jobs in the dependency chain from the point of failure or skip onwards. If you would like a job to run even if a job it is dependent on did not succeed, use the
always()conditional expression injobs.<job_id>.if.See: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds
-
expand_morelink
Ensure that only a single job or workflow using the same concurrency group will run at a time.
A concurrency group can be any string or expression. Allowed expression contexts:
github,inputs,vars,needs,strategy, andmatrix. For more information about expressions, see Evaluate expressions in workflows and actions.You can also specify concurrency at the workflow level. For more information, see
module.concurrency.This means that there can be at most one running and one pending job in a concurrency group at any time. When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. Any existing pending job or workflow in the same concurrency group, if it exists, will be canceled and the new queued job or workflow will take its place.
To also cancel any currently running job or workflow in the same concurrency group, specify
cancel-in-progress = true. To conditionally cancel currently running jobs or workflows in the same concurrency group, you can specifycancel-in-progressas an expression with any of the allowed expression contexts.Note:
The concurrency group name is case insensitive. For example,
prodandProdwill be treated as the same concurrency group. Ordering is not guaranteed for jobs or workflow runs using concurrency groups. Jobs or workflow runs in the same concurrency group are handled in an arbitrary order. -
expand_morelink
Use
jobs.<job_id>.strategyto use a matrix strategy for your jobs.A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based on the combinations of the variables. For example, you can use a matrix strategy to test your code in multiple versions of a language or on multiple operating systems.
For more information, see Running variations of jobs in a workflow.
-
expand_morelink
For a specific job, you can use
jobs.<job_id>.permissionsto modify the default permissions granted to theGITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access. For more information, see UseGITHUB_TOKENfor authentication in workflows.By specifying the permission within a job definition, you can configure a different set of permissions for the
GITHUB_TOKENfor each job, if required. Alternatively, you can specify the permissions for all jobs in the workflow. For information on defining permissions at the workflow level, seemodule.permissions.For each of the available permissions, shown in the table below, you can assign one of the access levels: read (if applicable), write, or none. write includes read. If you specify the access for any of these permissions, all of those that are not specified are set to none.
-
expand_morelink
Use
jobs.<job_id>.runs-onto define the type of machine to run the job on.The destination machine can be either a GitHub-hosted runner, larger runner, or a self-hosted runner. You can target runners based on the labels assigned to them, or their group membership, or a combination of these.
You can provide runs-on as:
-
A single string
-
A single variable containing a string
-
An array of strings, variables containing strings, or a combination of both
-
A key-value pair using the group or labels keys
-
If you specify an array of strings or variables, your workflow will execute on any runner that matches all of the specified runs-on values. For example, here the job will only run on a self-hosted runner that has the labels
linux,x64, andgpu:`runs-on` { "self-hosted"; "linux"; "x64"; "gpu" }For more information, see Choosing self-hosted runners.
-
You can mix strings and variables in an array. For example:
on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world!
If you would like to run your workflow on multiple machines, use
strategy. -
-
-
expand_morelinkenv: EnvironmentVariables?
Sets variables for steps to use in the runner environment.
You can also set variables for the entire workflow or a job. For more information, see env and jobs.<job_id>.env.
When more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.
Public actions may specify expected variables in the README file. If you are setting a secret or sensitive value, such as a password or token, you must set secrets using the secrets context. For more information, see Contexts reference.
-
expand_morelink
Craetes a map of outputs for a job.
Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see
needs.Outputs can be a maximum of 1 MB per job. The total of all outputs in a workflow run can be a maximum of 50 MB. Size is approximated based on UTF-16 encoding.
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.
If an output is skipped because it may contain a secret, you will see the following warning message: "Skip output {output.Key} since it may contain secret." For more information on how to handle secrets, please refer to the Example: Masking and passing a secret between jobs or workflows.
To use job outputs in a dependent job, you can use the needs context. For more information, see Contexts reference.
-
expand_morelink
A map of variables that are available to all steps in the job.
You can set variables for the entire workflow or an individual step. For more information, see env and jobs.<job_id>.steps
*.env.When more than one environment variable is defined with the same name, GitHub uses the most specific variable. For example, an environment variable defined in a step will override job and workflow environment variables with the same name, while the step executes. An environment variable defined for a job will override a workflow variable with the same name, while the job executes.
Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idenv
-
expand_morelink
A job contains a sequence of tasks called steps.
Steps can run commands, run setup tasks, or run an action in your repository, a public repository, or an action published in a Docker registry. Not all steps run actions, but all actions run as a step. Each step runs in its own process in the runner environment and has access to the workspace and filesystem. Because steps run in their own process, changes to environment variables are not preserved between steps. GitHub provides built-in steps to set up and complete a job.
GitHub only displays the first 1,000 checks, however, you can run an unlimited number of steps as long as you are within the workflow usage limits.
For more information, see Billing and usage for GitHub-hosted runners and Actions limits for self-hosted runner usage limits.
A name for the job, which is displayed in the GitHub UI