Task 1.1: Configure workflow triggers and events

• Acron '0 11 * * 1-5', which is 06:00 in New York expressed in UTC

  Incorrect

  Schedules default to UTC, so a fixed UTC hour lands at 07:00 local time for the part of the year when New York observes daylight saving.

• Bcron '0 6 * * 1-5' with timezone set to America/New_York under the schedule trigger

  Correct

  A schedule can name an IANA time zone, so 06:00 follows New York local time through both daylight saving changes, with one run a day.

• CTwo schedule entries, '0 10 * * 1-5' and '0 11 * * 1-5', one for each UTC offset of New York

  Incorrect

  Both cron entries fire every weekday, so the workflow starts twice a day instead of once.

• Dcron '0 6 * * 1-5', with TZ set to America/New_York in the workflow env

  Incorrect

  A workflow env variable only reaches the steps once a job runs; it doesn't change when the schedule fires, which stays UTC.

Scheduled workflows use POSIX cron syntax and run in UTC by default. The schedule trigger also accepts an IANA time zone string, so a cron entry paired with timezone America/New_York fires at 06:00 local time all year. When a time zone with daylight saving skips an hour, runs scheduled in that hour advance to the next valid time.

• AMove the repository to a paid plan so its schedules aren't throttled

  Incorrect

  Scheduled runs in public repositories don't stop for billing reasons; they stop after a period without repository activity.

• BRaise the Actions budget for the repository's owner

  Incorrect

  Standard GitHub-hosted runners are free in public repositories, so no budget was exhausted.

• CDelete the workflow's old runs so a new run can be queued

  Incorrect

  Run history doesn't block scheduling; the workflow itself was disabled.

• DEnable the workflow again from the Actions tab or the REST API

  Correct

  GitHub disables scheduled workflows in a public repository after 60 days with no activity; enabling the workflow brings the schedule back.

In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. A disabled workflow can be enabled again from the Actions tab, with GitHub CLI or through the REST API.

• Atypes: [success] under the workflow_run trigger

  Incorrect

  workflow_run has the activity types requested, in_progress and completed; success isn't one of them.

• BA condition on github.event.workflow_run.conclusion

  Correct

  workflow_run fires whatever the outcome, and the payload's conclusion tells the job whether Build succeeded.

• Cneeds: build on the publish job so it waits for Build

  Incorrect

  needs refers to jobs in the same workflow run; Build ran in another workflow.

• Dif: success() on the publish job

  Incorrect

  success() looks at earlier steps and jobs of this run, which have all succeeded, not at the run that triggered it.

A workflow_run workflow is triggered regardless of the conclusion of the triggering workflow. To act only on a successful run, check the github.event.workflow_run.conclusion property in a job or step condition, for example if github.event.workflow_run.conclusion == 'success'.

• APushing the tag v2.1.0 starts it only when the tagged commit changed a file under src/

  Incorrect

  The paths filter is set only under pull_request, and path filters aren't evaluated for pushes of tags anyway.

• BA pull request from release/1 into main that changes src/app.js doesn't start it

  Incorrect

  For pull_request, branches is matched against the base branch, main here, so the workflow runs.

• CPushing commits to main doesn't start it

  Correct

  When only tags are defined for push, the workflow doesn't run for pushes that affect branches.

• DWhen a pull request's changes skip the workflow, a required check that the workflow reports counts as passed

  Incorrect

  A check from a workflow skipped by a path or branch filter stays Pending, which blocks a merge that requires it.

• EA pull request into main that changes only docs/setup.md doesn't start it

  Correct

  With branches and paths both set, the workflow runs only when both filters match, and no changed file is under src/.

If only tags or only branches are defined for push, the workflow doesn't run for events that affect the other kind of ref. For pull requests, branches matches the base branch, and when both branches and paths are set, both must be satisfied. Path filters aren't evaluated for tag pushes. A check from a workflow skipped by filtering stays Pending, so a pull request that requires it is blocked.

• Agroup: staging, with no other settings

  Incorrect

  By default only one run can be pending in a group, and a newer pending run cancels the older one.

• Bgroup: staging and cancel-in-progress: true

  Incorrect

  That cancels the deployment that is running whenever a newer one arrives.

• Cgroup: staging, queue: max and cancel-in-progress: true

  Incorrect

  queue: max can't be combined with cancel-in-progress: true; the workflow fails validation.

• Dgroup: staging and queue: max

  Correct

  queue: max lets up to 100 runs wait in the group, processed one at a time in the order they began waiting.

A concurrency group allows one running job or workflow at a time. With the default queue setting, single, at most one can be pending and a new one replaces it, so intermediate deployments are canceled. queue: max lets up to 100 wait, processed first in, first out. queue: max with cancel-in-progress: true is a validation error.

• ARuns every two minutes, as long as each run finishes in time

  Incorrect

  Scheduled workflows can't run more often than every five minutes.

• BRuns no more often than once every five minutes

  Correct

  The shortest interval for scheduled workflows is once every five minutes.

• CThe workflow fails validation because step values aren't allowed

  Incorrect

  The / step operator is valid in any of the five cron fields.

• DRuns twice an hour, at minutes 0 and 2

  Incorrect

  */2 in the minute field means every second minute, and the five-minute minimum still applies.

Scheduled workflows use POSIX cron syntax, including the step operator. The shortest interval at which a scheduled workflow can run is once every five minutes, so a schedule of */2 doesn't run every two minutes.

• Astring, with a description that lists the allowed values

  Incorrect

  A string input accepts any text, so a typo would reach the run.

• Bnumber

  Incorrect

  A number input takes a numeric value, not one of three words.

• Cboolean, one per log level

  Incorrect

  Three checkboxes would allow several levels, or none, at once.

• Dchoice, with the values listed under options

  Correct

  A choice input offers only the listed options and resolves to one string.

A choice input lists its allowed values under options and resolves to the single selected string. A string input accepts any text, and a boolean input is either true or false.

• Apull_request with types: [closed] and if: github.event.pull_request.merged

  Correct

  A merged pull request is closed automatically, and the merged value tells the job whether the close came from a merge.

• Bpull_request with types: [merged]

  Incorrect

  merged isn't an activity type; a merge shows up as the closed type.

• Cpull_request with types: [closed] and no condition

  Incorrect

  closed also fires when a pull request is closed without being merged.

• Dpush to main, reading the pull request number from the push payload

  Incorrect

  Direct pushes to main start it too, and a push event isn't a pull request event.

When a pull request merges, it is automatically closed. To run a workflow when a pull request merges, use the pull_request event with the closed activity type and a conditional such as if: github.event.pull_request.merged == true, so a pull request closed without merging is skipped.

• AUse the pull_request_comment event instead

  Incorrect

  There is no such workflow event; comments on pull requests arrive as issue_comment.

• BAdd types: [pull_request] under issue_comment

  Incorrect

  issue_comment's activity types are created, edited and deleted.

• CRun the job only when github.event.issue.pull_request is set

  Correct

  That property is present only when the comment belongs to a pull request.

• DRun the job only when github.event_name is pull_request for that comment

  Incorrect

  The event name is issue_comment for both kinds of comment.

The issue_comment event occurs for comments on both issues and pull requests. A conditional on github.event.issue.pull_request runs a job only for pull request comments, and its negation only for issue comments.