package json

import "strings"

#Workflow: {
	@jsonschema(schema="http://json-schema.org/draft-07/schema")
	null | bool | number | 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.
		name?: 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.
		on: #event | [...#event] & [_, ...] | {
			// 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.
			check_run?: #eventObject & {
				types?: #types & [..."created" | "rerequested" | "completed" | "requested_action"] | *["created", "rerequested", "completed", "requested_action"]
				...
			}

			// 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/.
			check_suite?: #eventObject & {
				types?: #types & [..."completed" | "requested" | "rerequested"] | *["completed", "requested", "rerequested"]
				...
			}

			// 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.
			create?: #eventObject

			// 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.
			delete?: #eventObject

			// 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/.
			deployment?: #eventObject

			// 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.
			deployment_status?: #eventObject

			// 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.
			fork?: #eventObject

			// Runs your workflow when someone creates or updates a Wiki page,
			// which triggers the gollum event.
			gollum?: #eventObject

			// 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/.
			issue_comment?: #eventObject & {
				types?: #types & [..."created" | "edited" | "deleted"] | *["created", "edited", "deleted"]
				...
			}

			// 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.
			issues?: #eventObject & {
				types?: #types & [..."opened" | "edited" | "deleted" | "transferred" | "pinned" | "unpinned" | "closed" | "reopened" | "assigned" | "unassigned" | "labeled" | "unlabeled" | "locked" | "unlocked" | "milestoned" | "demilestoned"] | *["opened", "edited", "deleted", "transferred", "pinned", "unpinned", "closed", "reopened", "assigned", "unassigned", "labeled", "unlabeled", "locked", "unlocked", "milestoned", "demilestoned"]
				...
			}

			// 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/.
			label?: #eventObject & {
				types?: #types & [..."created" | "edited" | "deleted"] | *["created", "edited", "deleted"]
				...
			}

			// Runs your workflow anytime the member event occurs. More than
			// one activity type triggers this event. For information about
			// the REST API, see
			// https://developer.github.com/v3/repos/collaborators/.
			member?: #eventObject & {
				types?: #types & [..."added" | "edited" | "deleted"] | *["added", "edited", "deleted"]
				...
			}

			// 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/.
			milestone?: #eventObject & {
				types?: #types & [..."created" | "closed" | "opened" | "edited" | "deleted"] | *["created", "closed", "opened", "edited", "deleted"]
				...
			}

			// 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/.
			page_build?: #eventObject

			// 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/.
			project?: #eventObject & {
				types?: #types & [..."created" | "updated" | "closed" | "reopened" | "edited" | "deleted"] | *["created", "updated", "closed", "reopened", "edited", "deleted"]
				...
			}

			// 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.
			project_card?: #eventObject & {
				types?: #types & [..."created" | "moved" | "converted" | "edited" | "deleted"] | *["created", "moved", "converted", "edited", "deleted"]
				...
			}

			// 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.
			project_column?: #eventObject & {
				types?: #types & [..."created" | "updated" | "moved" | "deleted"] | *["created", "updated", "moved", "deleted"]
				...
			}

			// 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.
			public?: #eventObject

			// 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.
			pull_request?: #ref & {
				types?: #types & [..."assigned" | "unassigned" | "labeled" | "unlabeled" | "opened" | "edited" | "closed" | "reopened" | "synchronize" | "ready_for_review" | "locked" | "unlocked" | "review_requested" | "review_request_removed"] | *["opened", "synchronize", "reopened"]

				{[=~"^(branche|tag|path)s(-ignore)?$" & !~"^(types)$"]: _}
			}

			// 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.
			pull_request_review?: #eventObject & {
				types?: #types & [..."submitted" | "edited" | "dismissed"] | *["submitted", "edited", "dismissed"]
				...
			}

			// 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.
			pull_request_review_comment?: #eventObject & {
				types?: #types & [..."created" | "edited" | "deleted"] | *["created", "edited", "deleted"]
				...
			}

			// 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.
			pull_request_target?: #ref & {
				types?: #types & [..."assigned" | "unassigned" | "labeled" | "unlabeled" | "opened" | "edited" | "closed" | "reopened" | "synchronize" | "ready_for_review" | "locked" | "unlocked" | "review_requested" | "review_request_removed"] | *["opened", "synchronize", "reopened"]

				{[=~"^(branche|tag|path)s(-ignore)?$" & !~"^(types)$"]: _}
			}

			// 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.
			push?: #ref & {
				{[=~"^(branche|tag|path)s(-ignore)?$" & !~"^()$"]: _}
			}

			// 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.
			registry_package?: #eventObject & {
				types?: #types & [..."published" | "updated"] | *["published", "updated"]
				...
			}

			// 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.
			release?: #eventObject & {
				types?: #types & [..."published" | "unpublished" | "created" | "edited" | "deleted" | "prereleased" | "released"] | *["published", "unpublished", "created", "edited", "deleted", "prereleased", "released"]
				...
			}

			// 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/.
			status?: #eventObject

			// 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/.
			watch?: #eventObject

			// 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.
			workflow_dispatch?: null | bool | number | string | [...] | {
				// Input parameters allow you to specify data that the action
				// expects to use during runtime. GitHub stores input parameters
				// as environment variables. Input ids with uppercase letters are
				// converted to lowercase during runtime. We recommended using
				// lowercase input ids.
				inputs?: {
					{[=~"^[_a-zA-Z][a-zA-Z0-9_-]*$" & !~"^()$"]: {
						// A string description of the input parameter.
						description: string

						// A string shown to users using the deprecated input.
						deprecationMessage?: string

						// A boolean to indicate whether the action requires the input
						// parameter. Set to true when the parameter is required.
						required: bool

						// A string representing the default value. The default value is
						// used when an input parameter isn't specified in a workflow
						// file.
						default?: string
					}}
				}
				...
			}

			// 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.
			workflow_run?: #eventObject & {
				types?:     #types & [..."requested" | "completed"] | *["requested", "completed"]
				workflows?: [...string] & [_, ...]

				{[=~"^branches(-ignore)?$" & !~"^(types|workflows)$"]: _}
				...
			}

			// 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.
			repository_dispatch?: #eventObject

			// 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).
			schedule?: [...null | bool | number | string | [...] | {
				cron?: =~"^(((\\d+,)+\\d+|((\\d+|\\*)\\/\\d+|JAN|FEB|MAR|APR|MAY|JUN|JUL|AUG|SEP|OCT|NOV|DEC)|(\\d+-\\d+)|\\d+|\\*|MON|TUE|WED|THU|FRI|SAT|SUN) ?){5,7}$"
			}] & [_, ...]
		}

		// A map of environment variables that are available to all jobs
		// and steps in the workflow.
		env?: #env

		// A map of default settings that will apply to all jobs in the
		// workflow.
		defaults?: #defaults

		// 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.
		jobs: {
			{[=~"^[_a-zA-Z][a-zA-Z0-9_-]*$" & !~"^()$"]: {
				// The name of the job displayed on GitHub.
				name?: string

				// Identifies any jobs that must complete successfully before this
				// job will run. It can be a string or array of strings. If a job
				// fails, all jobs that need it are skipped unless the jobs use a
				// conditional statement that causes the job to continue.
				needs?: [...#name] & [_, ...] | #name

				// The type of machine to run the job on. The machine can be
				// either a GitHub-hosted runner, or a self-hosted runner.
				"runs-on": "macos-10.15" | "macos-11.0" | "macos-latest" | "self-hosted" | "ubuntu-16.04" | "ubuntu-18.04" | "ubuntu-20.04" | "ubuntu-latest" | "windows-2016" | "windows-2019" | "windows-latest" | (["self-hosted"] | ["self-hosted", #machine] | ["self-hosted", #architecture] | ["self-hosted", #machine, #architecture] | ["self-hosted", #architecture, #machine]) & [...] | #expressionSyntax

				// The environment that the job references.
				environment?: string | #environment

				// A map of outputs for a job. Job outputs are available to all
				// downstream jobs that depend on this job.
				outputs?: {
					[string]: string
				}

				// A map of environment variables that are available to all steps
				// in the job.
				env?: #env

				// A map of default settings that will apply to all steps in the
				// job.
				defaults?: #defaults

				// You can use the if conditional to prevent a job from running
				// unless a condition is met. You can use any supported context
				// and expression to create a conditional.
				// Expressions in an if conditional do not require the ${{ }}
				// syntax. For more information, see
				// https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.
				if?: string

				// A job contains a sequence of tasks called steps. Steps can run
				// commands, run setup tasks, or run an action in your
				// repository, a public repository, or an action published in a
				// Docker registry. Not all steps run actions, but all actions
				// run as a step. Each step runs in its own process in the
				// virtual environment and has access to the workspace and
				// filesystem. Because steps run in their own process, changes to
				// environment variables are not preserved between steps. GitHub
				// provides built-in steps to set up and complete a job.
				steps?: [...{
					// A unique identifier for the step. You can use the id to
					// reference the step in contexts. For more information, see
					// https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.
					id?: string

					// You can use the if conditional to prevent a step from running
					// unless a condition is met. You can use any supported context
					// and expression to create a conditional.
					// Expressions in an if conditional do not require the ${{ }}
					// syntax. For more information, see
					// https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.
					if?: string

					// A name for your step to display on GitHub.
					name?: string

					// Selects an action to run as part of a step in your job. An
					// action is a reusable unit of code. You can use an action
					// defined in the same repository as the workflow, a public
					// repository, or in a published Docker container image
					// (https://hub.docker.com/).
					// We strongly recommend that you include the version of the
					// action you are using by specifying a Git ref, SHA, or Docker
					// tag number. If you don't specify a version, it could break
					// your workflows or cause unexpected behavior when the action
					// owner publishes an update.
					// - Using the commit SHA of a released action version is the
					// safest for stability and security.
					// - Using the specific major action version allows you to receive
					// critical fixes and security patches while still maintaining
					// compatibility. It also assures that your workflow should still
					// work.
					// - Using the master branch of an action may be convenient, but
					// if someone releases a new major version with a breaking
					// change, your workflow could break.
					// Some actions require inputs that you must set using the with
					// keyword. Review the action's README file to determine the
					// inputs required.
					// Actions are either JavaScript files or Docker containers. If
					// the action you're using is a Docker container you must run the
					// job in a Linux virtual environment. For more details, see
					// https://help.github.com/en/articles/virtual-environments-for-github-actions.
					uses?: string

					// Runs command-line programs using the operating system's shell.
					// If you do not provide a name, the step name will default to
					// the text specified in the run command.
					// Commands run using non-login shells by default. You can choose
					// a different shell and customize the shell used to run
					// commands. For more information, see
					// https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#using-a-specific-shell.
					// Each run keyword represents a new process and shell in the
					// virtual environment. When you provide multi-line commands,
					// each line runs in the same shell.
					run?: string, "working-directory"?: #["working-directory"], shell?: #shell

					// A map of the input parameters defined by the action. Each input
					// parameter is a key/value pair. Input parameters are set as
					// environment variables. The variable is prefixed with INPUT_
					// and converted to upper case.
					with?: #env & {
						args?: string, entrypoint?: string, ...
					}

					// Sets environment variables for steps to use in the virtual
					// environment. You can also set environment variables for the
					// entire workflow or a job.
					env?: #env

					// Prevents a job from failing when a step fails. Set to true to
					// allow a job to pass when this step fails.
					"continue-on-error"?: bool | #expressionSyntax | *false

					// The maximum number of minutes to run the step before killing
					// the process.
					"timeout-minutes"?: number
				}] & [_, ...]

				// The maximum number of minutes to let a workflow run before
				// GitHub automatically cancels it. Default: 360
				"timeout-minutes"?: number | *360

				// A strategy creates a build matrix for your jobs. You can define
				// different variations of an environment to run each job in.
				strategy?: {
					// A build matrix is a set of different configurations of the
					// virtual environment. For example you might run a job against
					// more than one supported version of a language, operating
					// system, or tool. Each configuration is a copy of the job that
					// runs and reports a status.
					// You can specify a matrix by supplying an array for the
					// configuration options. For example, if the GitHub virtual
					// environment supports Node.js versions 6, 8, and 10 you could
					// specify an array of those versions in the matrix.
					// When you define a matrix of operating systems, you must set the
					// required runs-on keyword to the operating system of the
					// current job, rather than hard-coding the operating system
					// name. To access the operating system name, you can use the
					// matrix.os context parameter to set runs-on. For more
					// information, see
					// https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions.
					matrix: ({
						...
					} | #expressionSyntax) & {
						{[=~"^(in|ex)clude$" & !~"^()$"]: [...{
											[string]: #configuration
						}] & [_, ...]}
						{[!~"^(in|ex)clude$" & !~"^()$"]: [...#configuration] & [_, ...]}
					}

					// When set to true, GitHub cancels all in-progress jobs if any
					// matrix job fails. Default: true
					"fail-fast"?: bool | *true

					// The maximum number of jobs that can run simultaneously when
					// using a matrix job strategy. By default, GitHub will maximize
					// the number of jobs run in parallel depending on the available
					// runners on GitHub-hosted virtual machines.
					"max-parallel"?: number
				}

				// Prevents a workflow run from failing when a job fails. Set to
				// true to allow a workflow run to pass when this job fails.
				"continue-on-error"?: bool | #expressionSyntax

				// A container to run any steps in a job that don't already
				// specify a container. If you have steps that use both script
				// and container actions, the container actions will run as
				// sibling containers on the same network with the same volume
				// mounts.
				// If you do not set a container, all steps will run directly on
				// the host specified by runs-on unless a step refers to an
				// action configured to run in a container.
				container?: string | #container

				// Additional containers to host services for a job in a workflow.
				// These are useful for creating databases or cache services like
				// redis. The runner on the virtual machine will automatically
				// create a network and manage the life cycle of the service
				// containers.
				// When you use a service container for a job or your step uses
				// container actions, you don't need to set port information to
				// access the service. Docker automatically exposes all ports
				// between containers on the same network.
				// When both the job and the action run in a container, you can
				// directly reference the container by its hostname. The hostname
				// is automatically mapped to the service name.
				// When a step does not use a container action, you must access
				// the service using localhost and bind the ports.
				services?: {
					[string]: #container
				}
			}}
		}
	}

	#architecture: "ARM32" | "x64" | "x86"

	#branch: #globs

	#configuration: string | number | bool | {
		[string]: #configuration
	} | [...#configuration]

	#container: {
		// The Docker image to use as the container to run the action. The
		// value can be the Docker Hub image name or a registry name.
		image: string

		// If the image's container registry requires authentication to
		// pull the image, you can use credentials to set a map of the
		// username and password. The credentials are the same values
		// that you would provide to the `docker login` command.
		credentials?: {
			username?: string
			password?: string
			...
		}

		// Sets an array of environment variables in the container.
		env?: #env

		// Sets an array of ports to expose on the container.
		ports?: [...number | string] & [_, ...]

		// Sets an array of volumes for the container to use. You can use
		// volumes to share data between services or other steps in a
		// job. You can specify named Docker volumes, anonymous Docker
		// volumes, or bind mounts on the host.
		// To specify a volume, you specify the source and destination
		// path: <source>:<destinationPath>
		// The <source> is a volume name or an absolute path on the host
		// machine, and <destinationPath> is an absolute path in the
		// container.
		volumes?: [...=~"^[^:]+:[^:]+$"] & [_, ...]

		// Additional Docker container resource options. For a list of
		// options, see
		// https://docs.docker.com/engine/reference/commandline/create/#options.
		options?: string
	}

	#defaults: run?: {
		shell?:               #shell
		"working-directory"?: #["working-directory"]
	}

	#env: [string]: bool | number | string

	#environment: {
		// The name of the environment configured in the repo.
		name: string

		// A deployment URL
		url?: string
	}

	#event: "check_run" | "check_suite" | "create" | "delete" | "deployment" | "deployment_status" | "fork" | "gollum" | "issue_comment" | "issues" | "label" | "member" | "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_dispatch" | "workflow_run" | "repository_dispatch"

	#eventObject: null | {
		...
	}

	#expressionSyntax: =~"^\\$\\{\\{.*\\}\\}$"

	#globs: [...strings.MinRunes(1)] & [_, ...]

	#machine: "linux" | "macos" | "windows"

	#name: =~"^[_a-zA-Z][a-zA-Z0-9_-]*$"

	#path: #globs

	#ref: null | {
		branches?:          #branch
		"branches-ignore"?: #branch
		tags?:              #branch
		"tags-ignore"?:     #branch
		paths?:             #path
		"paths-ignore"?:    #path
		...
	}

	#shell: (string | ("bash" | "pwsh" | "python" | "sh" | "cmd" | "powershell")) & string

	#types: [_, ...]

	#: "working-directory": string
}