Merge pull request #16690 from github/repo-sync

repo sync

content/actions/hosting-your-own-runners/index.md

@@ -19,6 +19,7 @@ children:
   - /about-self-hosted-runners
   - /adding-self-hosted-runners
   - /autoscaling-with-self-hosted-runners
+  - /running-scripts-before-or-after-a-job
   - /configuring-the-self-hosted-runner-application-as-a-service
   - /using-a-proxy-server-with-self-hosted-runners
   - /using-labels-with-self-hosted-runners

content/actions/hosting-your-own-runners/running-scripts-before-or-after-a-job.md

@@ -0,0 +1,76 @@
+---
+title: Running scripts before or after a job
+intro: 'Scripts can automatically execute on a self-hosted runner, directly before or after a job.'
+versions:
+  feature: 'job-hooks-for-runners'
+type: tutorial
+miniTocMaxHeadingLevel: 3
+shortTitle: Run a script before or after a job
+---
+
+{% note %}
+
+**Note**: This feature is currently in beta and is subject to change.
+
+{% endnote %}
+
+## About pre- and post-job scripts
+
+You can automatically execute scripts on a self-hosted runner, either before a job runs, or after a job finishes running. You could use these scripts to support the job's requirements, such as building or tearing down a runner environment, or cleaning out directories. You could also use these scripts to track telemetry of how your runners are used.
+
+The custom scripts are automatically triggered when a specific environment variable is set on the runner; the environment variable must contain the absolute path to the script. For more information, see "[Triggering the scripts](#triggering-the-scripts)" below.
+
+The following scripting languages are supported:
+
+- **Bash**: Uses `bash` and can fallback to `sh`. Executes by running `-e {pathtofile}`.
+- **PowerShell**: Uses `pwsh` and can fallback to `powershell`. Executes by running `-command \". '{pathtofile}'\"`.
+
+## Writing the scripts
+
+Your custom scripts can use the following features:
+
+- **Environment variables**:  Scripts have access to the default environment variables. The full webhook event payload can be found in `GITHUB_EVENT_PATH`. For more information, see "[Environment variables](/actions/learn-github-actions/environment-variables#default-environment-variables)."
+- **Workflow commands**: Scripts can use workflow commands. For more information, see ["Workflow commands for {% data variables.product.prodname_actions %}"](/actions/using-workflows/workflow-commands-for-github-actions), with the exception of `save-state` and `set-output`, which are not supported by these scripts. Scripts can also use environment files. For more information, see [Environment files](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
+
+{% note %}
+
+**Note**: Avoid using your scripts to output sensitive information to the console, as anyone with read access to the repository might be able to see the output in the UI logs.
+
+{% endnote %}
+
+### Handling exit codes
+
+For pre-job scripts, exit code `0` indicates that the script completed successfully, and the job will then proceed to run. If there is any other exit code, the job will not run and will be marked as failed. To see the results of your pre-job scripts, check the logs for `Set up runner` entries. For more information on checking the logs, see "[Viewing logs to diagnose failures](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)."
+
+The [`continue-on-error`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error) setting is not supported for use by these scripts.
+
+## Triggering the scripts
+
+The custom scripts must be located on the runner, but should not be stored in the `actions-runner` application directory. The scripts are executed in the security context of the service account that's running the runner service.
+
+{% note %}
+
+**Note**: The triggered scripts are processed synchronously, so they will block job execution while they are running.
+
+{% endnote %}
+
+The scripts are automatically executed when the runner has the following environment variables containing an absolute path to the script:
+- `ACTIONS_RUNNER_HOOK_JOB_STARTED`: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
+- `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`: The script defined in this environment variable is triggered after the job has finished processing.
+
+To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory. For example, the following `.env` entry will have the runner automatically run a script named `cleanup_script.sh` before each job runs:
+
+```bash
+ACTIONS_RUNNER_HOOK_JOB_STARTED=/cleanup_script.sh
+```
+
+## Troubleshooting
+
+
+### No timeout setting
+
+There is currently no timeout setting available for scripts executed by `ACTIONS_RUNNER_HOOK_JOB_STARTED` or `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`. As a result, you could consider adding timeout handling to your script.
+
+### Reviewing the workflow run log
+
+To confirm whether your scripts are executing, you can review the logs for that job. The scripts will be listed within separate steps for either `Set up runner` or `Complete runner`, depending on which environment variable is triggering the script. For more information on checking the logs, see "[Viewing logs to diagnose failures](/actions/monitoring-and-troubleshooting-workflows/using-workflow-run-logs#viewing-logs-to-diagnose-failures)."

content/admin/enterprise-management/caching-repositories/about-repository-caching.md

@@ -16,6 +16,6 @@ A repository cache eliminates the need for {% data variables.product.product_nam
 
 The repository cache listens to the primary instance, whether that's a single instance or a geo-replicated set of instances, for changes to Git data. CI farms and other read-heavy consumers clone and fetch from the repository cache instead of the primary instance. Changes are propagated across the network, at periodic intervals, once per cache instance rather than once per client. Git data will typically be visible on the repository cache within several minutes after the data is pushed to the primary instance.  {% ifversion ghes > 3.3 %}The [`cache_sync` webhook](/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#cache_sync) can be used by CI systems to react to data being available in the cache.{% endif %}
 
-You have fine-grained control over which repositories are allowed to sync to the repository cache.
+You have fine-grained control over which repositories are allowed to sync to the repository cache. Git data will only be replicated to the locations you specify.
 
 {% data reusables.enterprise.repository-caching-config-summary %} For more information, see "[Configuring a repository cache](/admin/enterprise-management/caching-repositories/configuring-a-repository-cache)."

content/admin/enterprise-management/caching-repositories/configuring-a-repository-cache.md

@@ -69,6 +69,14 @@ Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will ins
 
 You can control data locality by configuring data location policies for your repositories with the `spokesctl cache-policy` command. Data location policies determine which repository networks are replicated on which repository caches. By default, no repository networks will be replicated on any repository caches until a data location policy is configured.
 
+Data location policies affect only Git content. Content in the database, such as issues and pull request comments, will be replicated to all nodes regardless of policy.
+
+{% note %}
+
+**Note:** Data location policies are not the same as access control. You must use repository roles to control which users may access a repository. For more information about repository roles, see "[Repository roles for an organization](/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)."
+
+{% endnote %} 
+
 You can configure a policy to replicate all networks with the `--default` flag. For example, this command will create a policy to replicate a single copy of every repository network to the set of repository caches whose `cache_location` is "kansas".
 
  ```

data/features/job-hooks-for-runners.yml

@@ -0,0 +1,5 @@
+# Reference: #6530
+# Running scripts before or after a job
+versions:
+  fpt: '*'
+  ghec: '*'

tests/rendering/signup-button.js

@@ -1,7 +1,10 @@
+import { jest, describe, expect } from '@jest/globals'
+
 import { getDOM } from '../helpers/e2etest.js'
-import { describe, expect } from '@jest/globals'
 
 describe('GHEC sign up button', () => {
+  jest.setTimeout(60 * 1000)
+
   test('present by default', async () => {
     const $ = await getDOM('/en')
     expect($('a[href^="https://github.com/signup"]').length).toBeGreaterThan(0)