-
Notifications
You must be signed in to change notification settings - Fork 292
[docs] Update glossary - daily scan 2026-03-05 #19712
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -187,10 +187,18 @@ A workflow configuration field (`stop-after:`) that automatically prevents new r | |||||
|
|
||||||
| Events that cause a workflow to run, defined in the `on:` section of frontmatter. Includes issue events, pull requests, schedules, manual runs, and slash commands. | ||||||
|
|
||||||
| ### Trigger File | ||||||
|
|
||||||
| A plain GitHub Actions workflow (`.yml`) that separates trigger definitions from agentic workflow logic. Calls a compiled orchestrator's `workflow_call` entry point in response to any GitHub event (issues, pushes, labels, manual dispatch). Decouples trigger changes from the compilation cycle — updating when an orchestrator runs requires editing only the trigger file, not recompiling the agentic workflow. See [CentralRepoOps](/gh-aw/patterns/central-repo-ops/). | ||||||
|
|
||||||
| ### Weekday Schedules | ||||||
|
|
||||||
| Scheduled workflows configured to run only Monday through Friday using `daily on weekdays` syntax. Recommended for daily workflows to avoid the "Monday wall of work" where tasks accumulate over weekends and create a backlog on Monday morning. The compiler converts this to cron expressions with `1-5` in the day-of-week field. Example: `schedule: daily on weekdays` generates a cron like `43 5 * * 1-5`. | ||||||
|
|
||||||
| ### workflow_call | ||||||
|
|
||||||
| A trigger enabling a compiled workflow to be invoked by another workflow in the same organization. Adding `workflow_call` to the `on:` section exposes the lock file as a callable workflow, with optional inputs callers can pass for context. Commonly used with a [Trigger File](#trigger-file) to decouple trigger definitions from agentic workflow compilation. See [CentralRepoOps](/gh-aw/patterns/central-repo-ops/). | ||||||
|
|
||||||
| ### workflow_dispatch | ||||||
|
|
||||||
| A manual trigger that runs a workflow on demand from the GitHub Actions UI or via the GitHub API. Requires explicit user initiation. | ||||||
|
|
@@ -261,6 +269,10 @@ Persistent storage for workflows preserving data between runs. Configured via `c | |||||
|
|
||||||
| Special triggers responding to slash commands in issue and PR comments. Configured using the `slash_command:` section with a command name. | ||||||
|
|
||||||
| ### Conclusion Job | ||||||
|
|
||||||
| An automatically generated job in compiled workflows that handles post-agent reporting and cleanup. Receives a workflow-specific concurrency group (`gh-aw-conclusion-{workflow-name}`) to prevent collision when multiple agent instances run the same workflow concurrently. Requires no manual configuration — the compiler sets the group automatically. See [Concurrency Control](/gh-aw/reference/concurrency/). | ||||||
|
||||||
| An automatically generated job in compiled workflows that handles post-agent reporting and cleanup. Receives a workflow-specific concurrency group (`gh-aw-conclusion-{workflow-name}`) to prevent collision when multiple agent instances run the same workflow concurrently. Requires no manual configuration — the compiler sets the group automatically. See [Concurrency Control](/gh-aw/reference/concurrency/). | |
| An automatically generated job in compiled workflows that handles post-agent reporting and cleanup. Receives a workflow-specific concurrency group (for example, `gh-aw-conclusion-{workflow-id}` derived from the workflow file name/ID) to prevent collision when multiple agent instances run the same workflow concurrently. Requires no manual configuration — the compiler sets the group automatically. See [Concurrency Control](/gh-aw/reference/concurrency/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In GitHub Actions, “labels” aren’t a top-level workflow trigger; label-based runs are typically
issues/pull_requestevents withtypes: [labeled]. Consider rephrasing this parenthetical to avoid implyinglabelsis its own event (e.g., “issue/PR label events”).