Merge pull request github#30690 from github/repo-sync

Repo sync

content/contributing/writing-for-github-docs/versioning-documentation.md

@@ -242,10 +242,6 @@ versions:
   feature: 'some-new-feature'
 ```
 
-### Schema enforcement
-
-The schema for validating the feature versioning lives in [`src/content-linter/lib/feature-versions-schema.js`](https://github.com/github/docs/blob/main/src/content-linter/lib/feature-versions-schema.js) and is exercised by [`tests/linting/lint-versioning.js`](https://github.com/github/docs/blob/main/src/content-linter/tests/lint-versioning.js).
-
 ## Best practices
 
 Versioned content impacts the reader, but also impacts anyone who contributes to or reviews the content. Here are a few tips to improve the writing, reading, and reviewing experience for versioning syntax. None of these practices are mandatory and you will find edge and corner cases, but they're intended as useful heuristics to help you think through versioning.

data/reusables/actions/jobs/section-defining-outputs-for-jobs.md

@@ -6,6 +6,12 @@ Job outputs containing expressions are evaluated on the runner at the end of eac
 
 To use job outputs in a dependent job, you can use the `needs` context. For more information, see "[AUTOTITLE](/actions/learn-github-actions/contexts#needs-context)."
 
+{% note %}
+
+**Note:** `$GITHUB_OUTPUT` is shared between all steps in a job. If you use the same output name in multiple steps, the last step to write to the output will override the value. If your job uses a matrix and writes to `$GITHUB_OUTPUT`, the content will be overwritten for each matrix combination. You can use the `matrix` context to create unique output names for each job configuration. For more information, see "[AUTOTITLE](/actions/learn-github-actions/contexts#matrix-context)."
+
+{% endnote %}
+
 ### Example: Defining outputs for a job
 
 {% raw %}