4b5e01365c
* Use in_progress workflow_job example, not queued ### tl;dr This changes the example `workflow_job` payload to be an `in_progress` event instead of `queued` event. ### why In #22174, I added some keys to the example workflow_job json. This was correct, but by adding non-null _values_, **I introduced a subtle bug**. It's a bug because a `queued` workflow is—by definition—_not_ yet assigned to a runner. So all the `runner_*` attributes will be `null` in the real world. After the workflow becomes `in_progress`, all the values are guaranteed to exist. So let's change the example to be an `in_progress` event, since it's a better example for documentation. * Explain more about the runner_* attributes in "workflow_job_properties.md" * Consistentize naming Co-authored-by: Martin Lopes <martin389@github.com> Co-authored-by: hubwriter <hubwriter@github.com>
Reusables
Reusables are long strings of reusable text.
Reusables are longer strings like paragraphs or procedural lists that can be referenced in multiple content files. Using Markdown (instead of YAML) makes it possible for our localization pipeline to split the strings into smaller translatable segments, leading to fewer translation errors and less churn when the source English content changes.
Each reusable lives in its own Markdown file.
The path and filename of each Markdown file determines what its path will be in the data object.
For example, a file named /data/reusables/foo/bar.md will be accessible as {% data reusables.foo.bar %} in pages.
Reusable files are divided generally into directories by task. For example, if you're creating a reusable string for articles about GitHub notifications, you'd add it in the directory data/reusables/notifications/ in a file named data/reusables/notifications/your-reusable-name.md. The content reference you'd add to the source would look like {% data reusables.notifications.your-reusable-name %}.