workflow.md

workflow

Index

• fn withConcurrency(value)
• fn withConcurrencyMixin(value)
• fn withDefaults(value)
• fn withDefaultsMixin(value)
• fn withEnv(value)
• fn withEnvMixin(value)
• fn withJobs(value)
• fn withJobsMixin(value)
• fn withName(value)
• fn withOn(value)
• fn withOnMixin(value)
• fn withPermissions(value)
• fn withPermissionsMixin(value)
• fn withRunName(value)
• obj concurrency
  • fn withCancelInProgress(value)
  • fn withCancelInProgressMixin(value)
  • fn withGroup(value)
  • obj cancel-in-progress
    • fn withExpressionSyntax(value)
• obj defaults
  • fn withRun(value)
  • fn withRunMixin(value)
  • obj run
    • fn withShell(value)
    • fn withShellMixin(value)
    • fn withWorkingDirectory(value)
• obj env
  • fn withStringContainingExpressionSyntax(value)
• obj on
  • fn withBranchProtectionRule(value)
  • fn withBranchProtectionRuleMixin(value)
  • fn withCheckRun(value)
  • fn withCheckRunMixin(value)
  • fn withCheckSuite(value)
  • fn withCheckSuiteMixin(value)
  • fn withCreate(value)
  • fn withCreateMixin(value)
  • fn withDelete(value)
  • fn withDeleteMixin(value)
  • fn withDeployment(value)
  • fn withDeploymentMixin(value)
  • fn withDeploymentStatus(value)
  • fn withDeploymentStatusMixin(value)
  • fn withDiscussion(value)
  • fn withDiscussionComment(value)
  • fn withDiscussionCommentMixin(value)
  • fn withDiscussionMixin(value)
  • fn withEvent(value)
  • fn withFork(value)
  • fn withForkMixin(value)
  • fn withGollum(value)
  • fn withGollumMixin(value)
  • fn withIssueComment(value)
  • fn withIssueCommentMixin(value)
  • fn withIssues(value)
  • fn withIssuesMixin(value)
  • fn withLabel(value)
  • fn withLabelMixin(value)
  • fn withMergeGroup(value)
  • fn withMergeGroupMixin(value)
  • fn withMilestone(value)
  • fn withMilestoneMixin(value)
  • fn withPageBuild(value)
  • fn withPageBuildMixin(value)
  • fn withProject(value)
  • fn withProjectCard(value)
  • fn withProjectCardMixin(value)
  • fn withProjectColumn(value)
  • fn withProjectColumnMixin(value)
  • fn withProjectMixin(value)
  • fn withPublic(value)
  • fn withPublicMixin(value)
  • fn withPullRequest(value)
  • fn withPullRequestMixin(value)
  • fn withPullRequestReview(value)
  • fn withPullRequestReviewComment(value)
  • fn withPullRequestReviewCommentMixin(value)
  • fn withPullRequestReviewMixin(value)
  • fn withPullRequestTarget(value)
  • fn withPullRequestTargetMixin(value)
  • fn withPush(value)
  • fn withPushMixin(value)
  • fn withRegistryPackage(value)
  • fn withRegistryPackageMixin(value)
  • fn withRelease(value)
  • fn withReleaseMixin(value)
  • fn withRepositoryDispatch(value)
  • fn withRepositoryDispatchMixin(value)
  • fn withSchedule(value)
  • fn withScheduleMixin(value)
  • fn withStatus(value)
  • fn withStatusMixin(value)
  • fn withWatch(value)
  • fn withWatchMixin(value)
  • fn withWorkflowCall(value)
  • fn withWorkflowDispatch(value)
  • fn withWorkflowRun(value)
  • fn withWorkflowRunMixin(value)
  • obj branch_protection_rule
    • fn withTypes(value=["created","edited","deleted"])
    • fn withTypesMixin(value=["created","edited","deleted"])
  • obj check_run
    • fn withTypes(value=["created","rerequested","completed","requested_action"])
    • fn withTypesMixin(value=["created","rerequested","completed","requested_action"])
  • obj check_suite
    • fn withTypes(value=["completed","requested","rerequested"])
    • fn withTypesMixin(value=["completed","requested","rerequested"])
  • obj discussion
    • fn withTypes(value=["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"])
    • fn withTypesMixin(value=["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"])
  • obj discussion_comment
    • fn withTypes(value=["created","edited","deleted"])
    • fn withTypesMixin(value=["created","edited","deleted"])
  • obj issue_comment
    • fn withTypes(value=["created","edited","deleted"])
    • fn withTypesMixin(value=["created","edited","deleted"])
  • obj issues
    • fn withTypes(value=["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"])
    • fn withTypesMixin(value=["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"])
  • obj label
    • fn withTypes(value=["created","edited","deleted"])
    • fn withTypesMixin(value=["created","edited","deleted"])
  • obj merge_group
    • fn withTypes(value=["checks_requested"])
    • fn withTypesMixin(value=["checks_requested"])
  • obj milestone
    • fn withTypes(value=["created","closed","opened","edited","deleted"])
    • fn withTypesMixin(value=["created","closed","opened","edited","deleted"])
  • obj project
    • fn withTypes(value=["created","updated","closed","reopened","edited","deleted"])
    • fn withTypesMixin(value=["created","updated","closed","reopened","edited","deleted"])
  • obj project_card
    • fn withTypes(value=["created","moved","converted","edited","deleted"])
    • fn withTypesMixin(value=["created","moved","converted","edited","deleted"])
  • obj project_column
    • fn withTypes(value=["created","updated","moved","deleted"])
    • fn withTypesMixin(value=["created","updated","moved","deleted"])
  • obj pull_request
    • fn withBranches(value)
    • fn withBranchesIgnore(value)
    • fn withBranchesIgnoreMixin(value)
    • fn withBranchesMixin(value)
    • fn withPaths(value)
    • fn withPathsIgnore(value)
    • fn withPathsIgnoreMixin(value)
    • fn withPathsMixin(value)
    • fn withTags(value)
    • fn withTagsIgnore(value)
    • fn withTagsIgnoreMixin(value)
    • fn withTagsMixin(value)
    • fn withTypes(value=["opened","synchronize","reopened"])
    • fn withTypesMixin(value=["opened","synchronize","reopened"])
  • obj pull_request_review
    • fn withTypes(value=["submitted","edited","dismissed"])
    • fn withTypesMixin(value=["submitted","edited","dismissed"])
  • obj pull_request_review_comment
    • fn withTypes(value=["created","edited","deleted"])
    • fn withTypesMixin(value=["created","edited","deleted"])
  • obj pull_request_target
    • fn withBranches(value)
    • fn withBranchesIgnore(value)
    • fn withBranchesIgnoreMixin(value)
    • fn withBranchesMixin(value)
    • fn withPaths(value)
    • fn withPathsIgnore(value)
    • fn withPathsIgnoreMixin(value)
    • fn withPathsMixin(value)
    • fn withTags(value)
    • fn withTagsIgnore(value)
    • fn withTagsIgnoreMixin(value)
    • fn withTagsMixin(value)
    • fn withTypes(value=["opened","synchronize","reopened"])
    • fn withTypesMixin(value=["opened","synchronize","reopened"])
  • obj push
    • fn withBranches(value)
    • fn withBranchesIgnore(value)
    • fn withBranchesIgnoreMixin(value)
    • fn withBranchesMixin(value)
    • fn withPaths(value)
    • fn withPathsIgnore(value)
    • fn withPathsIgnoreMixin(value)
    • fn withPathsMixin(value)
    • fn withTags(value)
    • fn withTagsIgnore(value)
    • fn withTagsIgnoreMixin(value)
    • fn withTagsMixin(value)
  • obj registry_package
    • fn withTypes(value=["published","updated"])
    • fn withTypesMixin(value=["published","updated"])
  • obj release
    • fn withTypes(value=["published","unpublished","created","edited","deleted","prereleased","released"])
    • fn withTypesMixin(value=["published","unpublished","created","edited","deleted","prereleased","released"])
  • obj workflow_run
    • fn withTypes(value=["requested","completed"])
    • fn withTypesMixin(value=["requested","completed"])
    • fn withWorkflows(value)
    • fn withWorkflowsMixin(value)
• obj permissions
  • fn withActions(value)
  • fn withAttestations(value)
  • fn withChecks(value)
  • fn withContents(value)
  • fn withDeployments(value)
  • fn withDiscussions(value)
  • fn withIdToken(value)
  • fn withIssues(value)
  • fn withPackages(value)
  • fn withPages(value)
  • fn withPullRequests(value)
  • fn withRepositoryProjects(value)
  • fn withSecurityEvents(value)
  • fn withStatuses(value)

Fields

fn withConcurrency

withConcurrency(value)

PARAMETERS:

• value (object,string)

Concurrency ensures 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. The expression can use any context except for the secrets context. You can also specify concurrency at the workflow level. 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 previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

fn withConcurrencyMixin

withConcurrencyMixin(value)

PARAMETERS:

• value (object,string)

Concurrency ensures 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. The expression can use any context except for the secrets context. You can also specify concurrency at the workflow level. 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 previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

fn withDefaults

withDefaults(value)

PARAMETERS:

• value (object)

A map of default settings that will apply to all jobs in the workflow.

fn withDefaultsMixin

withDefaultsMixin(value)

PARAMETERS:

• value (object)

A map of default settings that will apply to all jobs in the workflow.

fn withEnv

withEnv(value)

PARAMETERS:

• value (object,string)

To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the jobs.<job_id>.steps[*].env, jobs.<job_id>.env, and env keywords. For more information, see https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv

fn withEnvMixin

withEnvMixin(value)

PARAMETERS:

• value (object,string)

To set custom environment variables, you need to specify the variables in the workflow file. You can define environment variables for a step, job, or entire workflow using the jobs.<job_id>.steps[*].env, jobs.<job_id>.env, and env keywords. For more information, see https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsenv

fn withJobs

withJobs(value)

PARAMETERS:

• value (object)

A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the jobs.<job_id>.needs keyword. Each job runs in a fresh instance of the virtual 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 https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#usage-limits.

fn withJobsMixin

withJobsMixin(value)

PARAMETERS:

• value (object)

A workflow run is made up of one or more jobs. Jobs run in parallel by default. To run jobs sequentially, you can define dependencies on other jobs using the jobs.<job_id>.needs keyword. Each job runs in a fresh instance of the virtual 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 https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#usage-limits.

fn withName

withName(value)

PARAMETERS:

• value (string)

The name of your workflow. GitHub displays the names of your workflows on your repository's actions page. If you omit this field, GitHub sets the name to the workflow's filename.

fn withOn

withOn(value)

PARAMETERS:

• value (array,object,string)

The name of the GitHub event that triggers the workflow. You can provide a single event string, array of events, array of event types, or an event configuration map that schedules a workflow or restricts the execution of a workflow to specific files, tags, or branch changes. For a list of available events, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows.

fn withOnMixin

withOnMixin(value)

PARAMETERS:

• value (array,object,string)

The name of the GitHub event that triggers the workflow. You can provide a single event string, array of events, array of event types, or an event configuration map that schedules a workflow or restricts the execution of a workflow to specific files, tags, or branch changes. For a list of available events, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows.

fn withPermissions

withPermissions(value)

PARAMETERS:

• value (object,string)

You can modify the default permissions granted to the GITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access.

fn withPermissionsMixin

withPermissionsMixin(value)

PARAMETERS:

• value (object,string)

You can modify the default permissions granted to the GITHUB_TOKEN, adding or removing access as required, so that you only allow the minimum required access.

fn withRunName

withRunName(value)

PARAMETERS:

• value (string)

The name for workflow runs generated from the workflow. GitHub displays the workflow run name in the list of workflow runs on your repository's 'Actions' tab.

obj concurrency

fn concurrency.withCancelInProgress

concurrency.withCancelInProgress(value)

PARAMETERS:

• value (boolean,string)

To cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

fn concurrency.withCancelInProgressMixin

concurrency.withCancelInProgressMixin(value)

PARAMETERS:

• value (boolean,string)

To cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

fn concurrency.withGroup

concurrency.withGroup(value)

PARAMETERS:

• value (string)

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 previously pending job or workflow in the concurrency group will be canceled.

obj concurrency.cancel-in-progress

fn concurrency.cancel-in-progress.withExpressionSyntax

concurrency.cancel-in-progress.withExpressionSyntax(value)

PARAMETERS:

• value (string)

obj defaults

fn defaults.withRun

defaults.withRun(value)

PARAMETERS:

• value (object)

fn defaults.withRunMixin

defaults.withRunMixin(value)

PARAMETERS:

• value (object)

obj defaults.run

fn defaults.run.withShell

defaults.run.withShell(value)

PARAMETERS:

• value (string)

You can override the default shell settings in the runner's operating system using the shell keyword. You can use built-in shell keywords, or you can define a custom set of shell options.

fn defaults.run.withShellMixin

defaults.run.withShellMixin(value)

PARAMETERS:

• value (string)

You can override the default shell settings in the runner's operating system using the shell keyword. You can use built-in shell keywords, or you can define a custom set of shell options.

fn defaults.run.withWorkingDirectory

defaults.run.withWorkingDirectory(value)

PARAMETERS:

• value (string)

Using the working-directory keyword, you can specify the working directory of where to run the command.

obj env

fn env.withStringContainingExpressionSyntax

env.withStringContainingExpressionSyntax(value)

PARAMETERS:

• value (string)

obj on

fn on.withBranchProtectionRule

on.withBranchProtectionRule(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the branch_protection_rule event occurs. More than one activity type triggers this event.

fn on.withBranchProtectionRuleMixin

on.withBranchProtectionRuleMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the branch_protection_rule event occurs. More than one activity type triggers this event.

fn on.withCheckRun

on.withCheckRun(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the check_run event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/checks/runs.

fn on.withCheckRunMixin

on.withCheckRunMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the check_run event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/checks/runs.

fn on.withCheckSuite

on.withCheckSuite(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the check_suite event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/checks/suites/.

fn on.withCheckSuiteMixin

on.withCheckSuiteMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the check_suite event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/checks/suites/.

fn on.withCreate

on.withCreate(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone creates a branch or tag, which triggers the create event. For information about the REST API, see https://developer.github.com/v3/git/refs/#create-a-reference.

fn on.withCreateMixin

on.withCreateMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone creates a branch or tag, which triggers the create event. For information about the REST API, see https://developer.github.com/v3/git/refs/#create-a-reference.

fn on.withDelete

on.withDelete(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone deletes a branch or tag, which triggers the delete event. For information about the REST API, see https://developer.github.com/v3/git/refs/#delete-a-reference.

fn on.withDeleteMixin

on.withDeleteMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone deletes a branch or tag, which triggers the delete event. For information about the REST API, see https://developer.github.com/v3/git/refs/#delete-a-reference.

fn on.withDeployment

on.withDeployment(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone creates a deployment, which triggers the deployment event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see https://developer.github.com/v3/repos/deployments/.

fn on.withDeploymentMixin

on.withDeploymentMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone creates a deployment, which triggers the deployment event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see https://developer.github.com/v3/repos/deployments/.

fn on.withDeploymentStatus

on.withDeploymentStatus(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a third party provides a deployment status, which triggers the deployment_status event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see https://developer.github.com/v3/repos/deployments/#create-a-deployment-status.

fn on.withDeploymentStatusMixin

on.withDeploymentStatusMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a third party provides a deployment status, which triggers the deployment_status event. Deployments created with a commit SHA may not have a Git ref. For information about the REST API, see https://developer.github.com/v3/repos/deployments/#create-a-deployment-status.

fn on.withDiscussion

on.withDiscussion(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the discussion event occurs. More than one activity type triggers this event. For information about the GraphQL API, see https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions

fn on.withDiscussionComment

on.withDiscussionComment(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the discussion_comment event occurs. More than one activity type triggers this event. For information about the GraphQL API, see https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions

fn on.withDiscussionCommentMixin

on.withDiscussionCommentMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the discussion_comment event occurs. More than one activity type triggers this event. For information about the GraphQL API, see https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions

fn on.withDiscussionMixin

on.withDiscussionMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the discussion event occurs. More than one activity type triggers this event. For information about the GraphQL API, see https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions

fn on.withEvent

on.withEvent(value)

PARAMETERS:

• value (string)
  • valid values: "branch_protection_rule", "check_run", "check_suite", "create", "delete", "deployment", "deployment_status", "discussion", "discussion_comment", "fork", "gollum", "issue_comment", "issues", "label", "merge_group", "milestone", "page_build", "project", "project_card", "project_column", "public", "pull_request", "pull_request_review", "pull_request_review_comment", "pull_request_target", "push", "registry_package", "release", "status", "watch", "workflow_call", "workflow_dispatch", "workflow_run", "repository_dispatch"

fn on.withFork

on.withFork(value)

PARAMETERS:

• value (object)

Runs your workflow anytime when someone forks a repository, which triggers the fork event. For information about the REST API, see https://developer.github.com/v3/repos/forks/#create-a-fork.

fn on.withForkMixin

on.withForkMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime when someone forks a repository, which triggers the fork event. For information about the REST API, see https://developer.github.com/v3/repos/forks/#create-a-fork.

fn on.withGollum

on.withGollum(value)

PARAMETERS:

• value (object)

Runs your workflow when someone creates or updates a Wiki page, which triggers the gollum event.

fn on.withGollumMixin

on.withGollumMixin(value)

PARAMETERS:

• value (object)

Runs your workflow when someone creates or updates a Wiki page, which triggers the gollum event.

fn on.withIssueComment

on.withIssueComment(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the issue_comment event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/comments/.

fn on.withIssueCommentMixin

on.withIssueCommentMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the issue_comment event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/comments/.

fn on.withIssues

on.withIssues(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the issues event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues.

fn on.withIssuesMixin

on.withIssuesMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the issues event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues.

fn on.withLabel

on.withLabel(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the label event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/labels/.

fn on.withLabelMixin

on.withLabelMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the label event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/labels/.

fn on.withMergeGroup

on.withMergeGroup(value)

PARAMETERS:

• value (object)

Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For information about the merge queue, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue .

fn on.withMergeGroupMixin

on.withMergeGroupMixin(value)

PARAMETERS:

• value (object)

Runs your workflow when a pull request is added to a merge queue, which adds the pull request to a merge group. For information about the merge queue, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue .

fn on.withMilestone

on.withMilestone(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the milestone event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/milestones/.

fn on.withMilestoneMixin

on.withMilestoneMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the milestone event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/issues/milestones/.

fn on.withPageBuild

on.withPageBuild(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone pushes to a GitHub Pages-enabled branch, which triggers the page_build event. For information about the REST API, see https://developer.github.com/v3/repos/pages/.

fn on.withPageBuildMixin

on.withPageBuildMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone pushes to a GitHub Pages-enabled branch, which triggers the page_build event. For information about the REST API, see https://developer.github.com/v3/repos/pages/.

fn on.withProject

on.withProject(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/.

fn on.withProjectCard

on.withProjectCard(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project_card event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/cards.

fn on.withProjectCardMixin

on.withProjectCardMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project_card event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/cards.

fn on.withProjectColumn

on.withProjectColumn(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project_column event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/columns.

fn on.withProjectColumnMixin

on.withProjectColumnMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project_column event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/columns.

fn on.withProjectMixin

on.withProjectMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the project event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/projects/.

fn on.withPublic

on.withPublic(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone makes a private repository public, which triggers the public event. For information about the REST API, see https://developer.github.com/v3/repos/#edit.

fn on.withPublicMixin

on.withPublicMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime someone makes a private repository public, which triggers the public event. For information about the REST API, see https://developer.github.com/v3/repos/#edit.

fn on.withPullRequest

on.withPullRequest(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the pull_request event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestMixin

on.withPullRequestMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the pull_request event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestReview

on.withPullRequestReview(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the pull_request_review event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls/reviews. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestReviewComment

on.withPullRequestReviewComment(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a comment on a pull request's unified diff is modified, which triggers the pull_request_review_comment event. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls/comments. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestReviewCommentMixin

on.withPullRequestReviewCommentMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a comment on a pull request's unified diff is modified, which triggers the pull_request_review_comment event. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls/comments. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestReviewMixin

on.withPullRequestReviewMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the pull_request_review event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/pulls/reviews. Note: Workflows do not run on private base repositories when you open a pull request from a forked repository. When you create a pull request from a forked repository to the base repository, GitHub sends the pull_request event to the base repository and no pull request events occur on the forked repository. Workflows don't run on forked repositories by default. You must enable GitHub Actions in the Actions tab of the forked repository. The permissions for the GITHUB_TOKEN in forked repositories is read-only. For more information about the GITHUB_TOKEN, see https://help.github.com/en/articles/virtual-environments-for-github-actions.

fn on.withPullRequestTarget

on.withPullRequestTarget(value)

PARAMETERS:

• value (object)

This event is similar to pull_request, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run. For example, this event allows you to create workflows that label and comment on pull requests, based on the contents of the event payload.

fn on.withPullRequestTargetMixin

on.withPullRequestTargetMixin(value)

PARAMETERS:

• value (object)

This event is similar to pull_request, except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means that you can more safely make your secrets available to the workflows triggered by the pull request, because only workflows defined in the commit on the base repository are run. For example, this event allows you to create workflows that label and comment on pull requests, based on the contents of the event payload.

fn on.withPush

on.withPush(value)

PARAMETERS:

• value (object)

Runs your workflow when someone pushes to a repository branch, which triggers the push event. Note: The webhook payload available to GitHub Actions does not include the added, removed, and modified attributes in the commit object. You can retrieve the full commit object using the REST API. For more information, see https://developer.github.com/v3/repos/commits/#get-a-single-commit.

fn on.withPushMixin

on.withPushMixin(value)

PARAMETERS:

• value (object)

Runs your workflow when someone pushes to a repository branch, which triggers the push event. Note: The webhook payload available to GitHub Actions does not include the added, removed, and modified attributes in the commit object. You can retrieve the full commit object using the REST API. For more information, see https://developer.github.com/v3/repos/commits/#get-a-single-commit.

fn on.withRegistryPackage

on.withRegistryPackage(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a package is published or updated. For more information, see https://help.github.com/en/github/managing-packages-with-github-packages.

fn on.withRegistryPackageMixin

on.withRegistryPackageMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime a package is published or updated. For more information, see https://help.github.com/en/github/managing-packages-with-github-packages.

fn on.withRelease

on.withRelease(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the release event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/repos/releases/ in the GitHub Developer documentation.

fn on.withReleaseMixin

on.withReleaseMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the release event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/repos/releases/ in the GitHub Developer documentation.

fn on.withRepositoryDispatch

on.withRepositoryDispatch(value)

PARAMETERS:

• value (object)

You can use the GitHub API to trigger a webhook event called repository_dispatch when you want to trigger a workflow for activity that happens outside of GitHub. For more information, see https://developer.github.com/v3/repos/#create-a-repository-dispatch-event. To trigger the custom repository_dispatch webhook event, you must send a POST request to a GitHub API endpoint and provide an event_type name to describe the activity type. To trigger a workflow run, you must also configure your workflow to use the repository_dispatch event.

fn on.withRepositoryDispatchMixin

on.withRepositoryDispatchMixin(value)

PARAMETERS:

• value (object)

You can use the GitHub API to trigger a webhook event called repository_dispatch when you want to trigger a workflow for activity that happens outside of GitHub. For more information, see https://developer.github.com/v3/repos/#create-a-repository-dispatch-event. To trigger the custom repository_dispatch webhook event, you must send a POST request to a GitHub API endpoint and provide an event_type name to describe the activity type. To trigger a workflow run, you must also configure your workflow to use the repository_dispatch event.

fn on.withSchedule

on.withSchedule(value)

PARAMETERS:

• value (array)

You can schedule a workflow to run at specific UTC times using POSIX cron syntax (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 5 minutes. Note: GitHub Actions does not support the non-standard syntax @yearly, @monthly, @weekly, @daily, @hourly, and @reboot. You can use crontab guru (https://crontab.guru/). to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of crontab guru examples (https://crontab.guru/examples.html).

fn on.withScheduleMixin

on.withScheduleMixin(value)

PARAMETERS:

• value (array)

You can schedule a workflow to run at specific UTC times using POSIX cron syntax (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 5 minutes. Note: GitHub Actions does not support the non-standard syntax @yearly, @monthly, @weekly, @daily, @hourly, and @reboot. You can use crontab guru (https://crontab.guru/). to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of crontab guru examples (https://crontab.guru/examples.html).

fn on.withStatus

on.withStatus(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the status of a Git commit changes, which triggers the status event. For information about the REST API, see https://developer.github.com/v3/repos/statuses/.

fn on.withStatusMixin

on.withStatusMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the status of a Git commit changes, which triggers the status event. For information about the REST API, see https://developer.github.com/v3/repos/statuses/.

fn on.withWatch

on.withWatch(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the watch event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/activity/starring/.

fn on.withWatchMixin

on.withWatchMixin(value)

PARAMETERS:

• value (object)

Runs your workflow anytime the watch event occurs. More than one activity type triggers this event. For information about the REST API, see https://developer.github.com/v3/activity/starring/.

fn on.withWorkflowCall

on.withWorkflowCall(value)

PARAMETERS:

• value (string)

Allows workflows to be reused by other workflows.

fn on.withWorkflowDispatch

on.withWorkflowDispatch(value)

PARAMETERS:

• value (string)

You can now create workflows that are manually triggered with the new workflow_dispatch event. You will then see a 'Run workflow' button on the Actions tab, enabling you to easily trigger a run.

fn on.withWorkflowRun

on.withWorkflowRun(value)

PARAMETERS:

• value (object)

This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. For example, if your pull_request workflow generates build artifacts, you can create a new workflow that uses workflow_run to analyze the results and add a comment to the original pull request.

fn on.withWorkflowRunMixin

on.withWorkflowRunMixin(value)

PARAMETERS:

• value (object)

This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. For example, if your pull_request workflow generates build artifacts, you can create a new workflow that uses workflow_run to analyze the results and add a comment to the original pull request.

obj on.branch_protection_rule

fn on.branch_protection_rule.withTypes

on.branch_protection_rule.withTypes(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.branch_protection_rule.withTypesMixin

on.branch_protection_rule.withTypesMixin(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.check_run

fn on.check_run.withTypes

on.check_run.withTypes(value=["created","rerequested","completed","requested_action"])

PARAMETERS:

• value (array)
  • default value: ["created","rerequested","completed","requested_action"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.check_run.withTypesMixin

on.check_run.withTypesMixin(value=["created","rerequested","completed","requested_action"])

PARAMETERS:

• value (array)
  • default value: ["created","rerequested","completed","requested_action"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.check_suite

fn on.check_suite.withTypes

on.check_suite.withTypes(value=["completed","requested","rerequested"])

PARAMETERS:

• value (array)
  • default value: ["completed","requested","rerequested"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.check_suite.withTypesMixin

on.check_suite.withTypesMixin(value=["completed","requested","rerequested"])

PARAMETERS:

• value (array)
  • default value: ["completed","requested","rerequested"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.discussion

fn on.discussion.withTypes

on.discussion.withTypes(value=["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.discussion.withTypesMixin

on.discussion.withTypesMixin(value=["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted","transferred","pinned","unpinned","labeled","unlabeled","locked","unlocked","category_changed","answered","unanswered"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.discussion_comment

fn on.discussion_comment.withTypes

on.discussion_comment.withTypes(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.discussion_comment.withTypesMixin

on.discussion_comment.withTypesMixin(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.issue_comment

fn on.issue_comment.withTypes

on.issue_comment.withTypes(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.issue_comment.withTypesMixin

on.issue_comment.withTypesMixin(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.issues

fn on.issues.withTypes

on.issues.withTypes(value=["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"])

PARAMETERS:

• value (array)
  • default value: ["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.issues.withTypesMixin

on.issues.withTypesMixin(value=["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"])

PARAMETERS:

• value (array)
  • default value: ["opened","edited","deleted","transferred","pinned","unpinned","closed","reopened","assigned","unassigned","labeled","unlabeled","locked","unlocked","milestoned","demilestoned"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.label

fn on.label.withTypes

on.label.withTypes(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.label.withTypesMixin

on.label.withTypesMixin(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.merge_group

fn on.merge_group.withTypes

on.merge_group.withTypes(value=["checks_requested"])

PARAMETERS:

• value (array)
  • default value: ["checks_requested"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.merge_group.withTypesMixin

on.merge_group.withTypesMixin(value=["checks_requested"])

PARAMETERS:

• value (array)
  • default value: ["checks_requested"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.milestone

fn on.milestone.withTypes

on.milestone.withTypes(value=["created","closed","opened","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","closed","opened","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.milestone.withTypesMixin

on.milestone.withTypesMixin(value=["created","closed","opened","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","closed","opened","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.project

fn on.project.withTypes

on.project.withTypes(value=["created","updated","closed","reopened","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","updated","closed","reopened","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.project.withTypesMixin

on.project.withTypesMixin(value=["created","updated","closed","reopened","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","updated","closed","reopened","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.project_card

fn on.project_card.withTypes

on.project_card.withTypes(value=["created","moved","converted","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","moved","converted","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.project_card.withTypesMixin

on.project_card.withTypesMixin(value=["created","moved","converted","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","moved","converted","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.project_column

fn on.project_column.withTypes

on.project_column.withTypes(value=["created","updated","moved","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","updated","moved","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.project_column.withTypesMixin

on.project_column.withTypesMixin(value=["created","updated","moved","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","updated","moved","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.pull_request

fn on.pull_request.withBranches

on.pull_request.withBranches(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withBranchesIgnore

on.pull_request.withBranchesIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withBranchesIgnoreMixin

on.pull_request.withBranchesIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withBranchesMixin

on.pull_request.withBranchesMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withPaths

on.pull_request.withPaths(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request.withPathsIgnore

on.pull_request.withPathsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request.withPathsIgnoreMixin

on.pull_request.withPathsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request.withPathsMixin

on.pull_request.withPathsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request.withTags

on.pull_request.withTags(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withTagsIgnore

on.pull_request.withTagsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withTagsIgnoreMixin

on.pull_request.withTagsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withTagsMixin

on.pull_request.withTagsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request.withTypes

on.pull_request.withTypes(value=["opened","synchronize","reopened"])

PARAMETERS:

• value (array)
  • default value: ["opened","synchronize","reopened"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.pull_request.withTypesMixin

on.pull_request.withTypesMixin(value=["opened","synchronize","reopened"])

PARAMETERS:

• value (array)
  • default value: ["opened","synchronize","reopened"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.pull_request_review

fn on.pull_request_review.withTypes

on.pull_request_review.withTypes(value=["submitted","edited","dismissed"])

PARAMETERS:

• value (array)
  • default value: ["submitted","edited","dismissed"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.pull_request_review.withTypesMixin

on.pull_request_review.withTypesMixin(value=["submitted","edited","dismissed"])

PARAMETERS:

• value (array)
  • default value: ["submitted","edited","dismissed"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.pull_request_review_comment

fn on.pull_request_review_comment.withTypes

on.pull_request_review_comment.withTypes(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.pull_request_review_comment.withTypesMixin

on.pull_request_review_comment.withTypesMixin(value=["created","edited","deleted"])

PARAMETERS:

• value (array)
  • default value: ["created","edited","deleted"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.pull_request_target

fn on.pull_request_target.withBranches

on.pull_request_target.withBranches(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withBranchesIgnore

on.pull_request_target.withBranchesIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withBranchesIgnoreMixin

on.pull_request_target.withBranchesIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withBranchesMixin

on.pull_request_target.withBranchesMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withPaths

on.pull_request_target.withPaths(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request_target.withPathsIgnore

on.pull_request_target.withPathsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request_target.withPathsIgnoreMixin

on.pull_request_target.withPathsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request_target.withPathsMixin

on.pull_request_target.withPathsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.pull_request_target.withTags

on.pull_request_target.withTags(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withTagsIgnore

on.pull_request_target.withTagsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withTagsIgnoreMixin

on.pull_request_target.withTagsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withTagsMixin

on.pull_request_target.withTagsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.pull_request_target.withTypes

on.pull_request_target.withTypes(value=["opened","synchronize","reopened"])

PARAMETERS:

• value (array)
  • default value: ["opened","synchronize","reopened"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.pull_request_target.withTypesMixin

on.pull_request_target.withTypesMixin(value=["opened","synchronize","reopened"])

PARAMETERS:

• value (array)
  • default value: ["opened","synchronize","reopened"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.push

fn on.push.withBranches

on.push.withBranches(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withBranchesIgnore

on.push.withBranchesIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withBranchesIgnoreMixin

on.push.withBranchesIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withBranchesMixin

on.push.withBranchesMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withPaths

on.push.withPaths(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.push.withPathsIgnore

on.push.withPathsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.push.withPathsIgnoreMixin

on.push.withPathsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.push.withPathsMixin

on.push.withPathsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run when at least one file does not match paths-ignore or at least one modified file matches the configured paths. Path filters are not evaluated for pushes to tags. The paths-ignore and paths keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. You can exclude paths using two types of filters. You cannot use both of these filters for the same event in a workflow.

• paths-ignore - Use the paths-ignore filter when you only need to exclude path names.
• paths - Use the paths filter when you need to filter paths for positive matches and exclude paths.

fn on.push.withTags

on.push.withTags(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withTagsIgnore

on.push.withTagsIgnore(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withTagsIgnoreMixin

on.push.withTagsIgnoreMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

fn on.push.withTagsMixin

on.push.withTagsMixin(value)

PARAMETERS:

• value (array)

When using the push and pull_request events, you can configure a workflow to run on specific branches or tags. If you only define only tags or only branches, the workflow won't run for events affecting the undefined Git ref. The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one branch or tag name. For more information, see https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet. The patterns defined in branches and tags are evaluated against the Git ref's name. For example, defining the pattern mona/octocat in branches will match the refs/heads/mona/octocat Git ref. The pattern releases/** will match the refs/heads/releases/10 Git ref. You can use two types of filters to prevent a workflow from running on pushes and pull requests to tags and branches:

• branches or branches-ignore - You cannot use both the branches and branches-ignore filters for the same event in a workflow. Use the branches filter when you need to filter branches for positive matches and exclude branches. Use the branches-ignore filter when you only need to exclude branch names.
• tags or tags-ignore - You cannot use both the tags and tags-ignore filters for the same event in a workflow. Use the tags filter when you need to filter tags for positive matches and exclude tags. Use the tags-ignore filter when you only need to exclude tag names. You can exclude tags and branches using the ! character. The order that you define patterns matters.
• A matching negative pattern (prefixed with !) after a positive match will exclude the Git ref.
• A matching positive pattern after a negative match will include the Git ref again.

obj on.registry_package

fn on.registry_package.withTypes

on.registry_package.withTypes(value=["published","updated"])

PARAMETERS:

• value (array)
  • default value: ["published","updated"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.registry_package.withTypesMixin

on.registry_package.withTypesMixin(value=["published","updated"])

PARAMETERS:

• value (array)
  • default value: ["published","updated"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.release

fn on.release.withTypes

on.release.withTypes(value=["published","unpublished","created","edited","deleted","prereleased","released"])

PARAMETERS:

• value (array)
  • default value: ["published","unpublished","created","edited","deleted","prereleased","released"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.release.withTypesMixin

on.release.withTypesMixin(value=["published","unpublished","created","edited","deleted","prereleased","released"])

PARAMETERS:

• value (array)
  • default value: ["published","unpublished","created","edited","deleted","prereleased","released"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

obj on.workflow_run

fn on.workflow_run.withTypes

on.workflow_run.withTypes(value=["requested","completed"])

PARAMETERS:

• value (array)
  • default value: ["requested","completed"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.workflow_run.withTypesMixin

on.workflow_run.withTypesMixin(value=["requested","completed"])

PARAMETERS:

• value (array)
  • default value: ["requested","completed"]

Selects the types of activity that will trigger a workflow run. Most GitHub events are triggered by more than one type of activity. For example, the event for the release resource is triggered when a release is published, unpublished, created, edited, deleted, or prereleased. The types keyword enables you to narrow down activity that causes the workflow to run. When only one activity type triggers a webhook event, the types keyword is unnecessary. You can use an array of event types. For more information about each event and their activity types, see https://help.github.com/en/articles/events-that-trigger-workflows#webhook-events.

fn on.workflow_run.withWorkflows

on.workflow_run.withWorkflows(value)

PARAMETERS:

• value (array)

fn on.workflow_run.withWorkflowsMixin

on.workflow_run.withWorkflowsMixin(value)

PARAMETERS:

• value (array)

obj permissions

fn permissions.withActions

permissions.withActions(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withAttestations

permissions.withAttestations(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withChecks

permissions.withChecks(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withContents

permissions.withContents(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withDeployments

permissions.withDeployments(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withDiscussions

permissions.withDiscussions(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withIdToken

permissions.withIdToken(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withIssues

permissions.withIssues(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withPackages

permissions.withPackages(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withPages

permissions.withPages(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withPullRequests

permissions.withPullRequests(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withRepositoryProjects

permissions.withRepositoryProjects(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withSecurityEvents

permissions.withSecurityEvents(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"

fn permissions.withStatuses

permissions.withStatuses(value)

PARAMETERS:

• value (string)
  • valid values: "read", "write", "none"