com.github.action.Workflow0.0.6

You can also set variables that are only available to the steps of a single job or to a single step. For more information, see DefaultJob.env and Step.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.

A concurrency group can be any string or expression. The expression can only use github, inputs and vars contexts. For more information about expressions, see Evaluate expressions in workflows and actions.

You can also specify concurrency at the job level. For more information, see BaseJob.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 specify cancel-in-progress as an expression with any of the allowed expression contexts.

For more information, see Use GITHUB_TOKEN for authentication in workflows.

You can use permissions either as a top-level key, to apply to all jobs in the workflow, or within specific jobs. When you add the permissions key within a specific job, all actions and run commands within that job that use the GITHUB_TOKEN gain the access rights you specify. For more information, see BaseJob.permissions.

Owners of an organization can restrict write access for the GITHUB_TOKEN at the repository level. For more information, see Disabling or limiting GitHub Actions for your organization.

When a workflow is triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission, even when it is triggered from a public fork. For more information, see Events that trigger workflows.

Each job runs in a runner environment specified by runs-on.

You can run an unlimited number of jobs 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.

If you need to find the unique identifier of a job running in a workflow run, you can use the GitHub API.

For more information, see REST API endpoints for GitHub Actions.