crates/actions/tests/corpus/invalid · flagon-io/g1t

background-step.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

bare-event-with-settings.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

branches-and-ignore.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

call-input-type-missing.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

call-input-unexpected-property.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

call-output-value-missing.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

call-secret-unknown-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

caller-job-env.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

caller-secrets-word.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

concurrency-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

concurrency-without-group.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

container-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

credentials-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

defaults-run-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

defaults-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

dispatch-input-unknown-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

dispatch-unknown-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

environment-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

environment-without-name.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

g1t-not-mapping.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

g1t-not-under-strategy.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

job-id-case-duplicate.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

job-id-digit.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

job-id-dot.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

job-id-reserved.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

merge-key-list.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

merge-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

on-missing.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

permission-metadata.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

permission-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

push-branch-typo.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

push-inputs.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

push-types.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

root-true-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

runs-on-mapping-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

runs-on-missing.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

schedule-not-list.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

schedule-without-cron.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

service-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

shell-on-action-step.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

step-id-duplicate.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

step-id-invalid.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

step-uses-and-run.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

steps-mapping.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

strategy-unknown.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-event-in-list.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-event-in-mapping.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-event.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-job-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-root-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

unknown-step-key.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

uses-and-runs-on.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

uses-and-steps.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

wait-step.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday

with-on-run-step.ymlA workflow is read as GitHub reads it, from GitHub's own schema for workflow files, now kept in crates/actions/schema with its licence: a key GitHub doesn't have, at the top, on a job, a step, an event or any of their mappings, is refused and the message names the job and step and lists the keys that place can have; a job without `uses` needs `runs-on`, and one with `uses` has no `runs-on` or `steps`; job and step ids follow GitHub's rule and are compared without case; an event GitHub doesn't have, a filter its event doesn't take, or `branches` beside `branches-ignore` is refused; and a YAML merge key (`<<`) is refused, as GitHub does not read them, while anchors and aliases still work. `permissions: metadata` and other names GitHub's token lacks are refused, and names GitHub has that g1t has nothing behind still read and grant nothing. A `g1t:` mapping is allowed on the workflow, a job and a step, for g1t's own settings, and `g1t: { deployment: false }` on a job does what `environment.deployment: false` does. GitHub's background steps are refused, since g1t does not run them yet, and a schedule's `timezone`, `concurrency.queue`, `cancel-timeout-minutes` and `snapshot` read with a note that they are not applied. The actions guide says how workflows are checked and what `g1t:` may hold, and the limitations page lists what is not applied.yesterday