Merge branch 'main' into demographic

Author: jessephus

assets/images/help/business-accounts/download-invoice.png

@@ -10,6 +10,10 @@ redirect_from:
   - /actions/monitoring-and-troubleshooting-workflows/monitoring-workflows/notifications-for-workflow-runs
 ---
 
-{% data reusables.actions.enterprise-github-hosted-runners %}
+If you enable email or web notifications for {% data variables.product.prodname_actions %}, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed. For more information about enabling or disabling notifications, see [AUTOTITLE](/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications).
 
-{% data reusables.repositories.workflow-notifications %}
+Notifications for scheduled workflows are sent to the user who initially created the workflow.
+ * If a different user updates the cron syntax, in the `schedule` event in the workflow file, subsequent notifications will be sent to that user instead.
+ * If a scheduled workflow is disabled and then re-enabled, notifications will be sent to the user who re-enabled the workflow rather than the user who last modified the cron syntax.
+
+You can also see the status of workflow runs on a repository's Actions tab. For more information, see [AUTOTITLE](/actions/managing-workflow-runs).

assets/images/help/business-accounts/pay-invoice-button.png

@@ -966,58 +966,44 @@ jobs:
 
 | Webhook event payload | Activity types | `GITHUB_SHA` | `GITHUB_REF` |
 | --------------------- | -------------- | ------------ | -------------|
-| Not applicable | Not applicable | Last commit on default branch | Default branch | When the scheduled workflow is set to run. A scheduled workflow uses [POSIX cron syntax](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07). For more information, see [AUTOTITLE](/actions/using-workflows#triggering-a-workflow-with-events). |
+| Not applicable | Not applicable | Last commit on default branch | Default branch |
 
 > [!NOTE]
 > * {% data reusables.actions.schedule-delay %}
-> * This event will only trigger a workflow run if the workflow file is on the default branch.
+> * {% data reusables.actions.branch-requirement %}
 > * Scheduled workflows will only run on the default branch.
 > * In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days. For information on re-enabling a disabled workflow, see [AUTOTITLE](/enterprise-server/actions/using-workflows/disabling-and-enabling-a-workflow#enabling-a-workflow).
-> * For an enterprise with {% data variables.product.prodname_emus %}, scheduled workflows will not run if the last `actor` associated with the scheduled workflow has been deprovisioned (and therefore become suspended) by the {% data variables.product.prodname_emu %} identity provider (IdP). However, if the last `actor` {% data variables.product.prodname_emu %} has not been deprovisioned by the IdP, and has only been removed as a member from a given organization in the enterprise, scheduled workflows will still run with that user set as the `actor`. Similarly, for an enterprise without {% data variables.product.prodname_emus %}, removing a user from an organization will not prevent scheduled workflows which had that user as their `actor` from running. Essentially, triggering a scheduled workflow requires that the status of the `actor` user account associated with the workflow is currently active (i.e. not suspended or deleted). Thus, the _user account's_ status, in both {% data variables.product.prodname_emu %} and non-{% data variables.product.prodname_emu %} scenarios, is what's important, _not_ the user's _membership status_ in the organization where the scheduled workflow is located.
-> * Certain repository events change the `actor` associated with the workflow. For example, a user who changes the default branch of the repository, which changes the branch on which scheduled workflows run, becomes `actor` for those scheduled workflows.
-> * For a deactivated scheduled workflow, if a user with `write` permissions to the repository makes a commit that changes the `cron` schedule on the workflow, the workflow will be reactivated, and that user will become the `actor` associated with any workflow runs. Note that, in this situation, the workflow is not reactivated by any change to the workflow file; you must alter the `cron` value in the workflow and commit this change.
->
->   **Example:**
->
->   ```yaml
->   on:
->     schedule:
->       - cron: "15 4,5 * * *"   # <=== Change this value
->   ```
 
 The `schedule` event allows you to trigger a workflow at a scheduled time.
 
-{% data reusables.repositories.actions-scheduled-workflow-example %}
-
-Cron syntax has five fields separated by a space, and each field represents a unit of time.
-
-```text
-┌───────────── minute (0 - 59)
-│ ┌───────────── hour (0 - 23)
-│ │ ┌───────────── day of the month (1 - 31)
-│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
-│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
-│ │ │ │ │
-│ │ │ │ │
-│ │ │ │ │
-* * * * *
-```
+   **Example:**
 
-You can use these operators in any of the five fields:
+  ```yaml
+   on:
+     schedule:
+       - cron: "15 4,5 * * *"
+  ```
 
-| Operator | Description | Example |
-| -------- | ----------- | ------- |
-| * | Any value | `15 * * * *` runs at every minute 15 of every hour of every day. |
-| , | Value list separator | `2,10 4,5 * * *` runs at minute 2 and 10 of the 4th and 5th hour of every day. |
-| - | Range of values | `30 4-6 * * *` runs at minute 30 of the 4th, 5th, and 6th hour. |
-| / | Step values | `20/15 * * * *` runs every 15 minutes starting from minute 20 through 59 (minutes 20, 35, and 50). |
+{% data reusables.repositories.actions-scheduled-workflow-example %}
 
 > [!NOTE]
 > {% data variables.product.prodname_actions %} does not support the non-standard syntax `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly`, and `@reboot`.
 
 You can use [crontab guru](https://crontab.guru/) to help generate your cron syntax and confirm what time it will run. To help you get started, there is also a list of [crontab guru examples](https://crontab.guru/examples.html).
 
-Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/notifications-for-workflow-runs).
+### `actor` for scheduled workflows
+
+Certain repository events change the `actor` associated with the workflow. For example, a user who changes the default branch of the repository, which changes the branch on which scheduled workflows run, becomes `actor` for those scheduled workflows.
+
+For a deactivated scheduled workflow, if a user with `write` permissions to the repository makes a commit that changes the `cron` schedule on the workflow, the workflow will be reactivated, and that user will become the `actor` associated with any workflow runs.
+
+Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file.  For more information, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/notifications-for-workflow-runs).
+
+> [!NOTE]
+> For an enterprise with {% data variables.product.prodname_emus %}, triggering a scheduled workflow requires that the status of the `actor` user account associated with the workflow is currently active (i.e. not suspended or deleted).
+> * Scheduled workflows will not run if the last `actor` associated with the scheduled workflow has been deprovisioned by the {% data variables.product.prodname_emu %} identity provider (IdP). However, if the last `actor` {% data variables.product.prodname_emu %} has not been deprovisioned by the IdP, and has only been removed as a member from a given organization in the enterprise, scheduled workflows will still run with that user set as the `actor`.
+> * Similarly, for an enterprise without {% data variables.product.prodname_emus %}, removing a user from an organization will not prevent scheduled workflows which had that user as their `actor` from running.  
+> * Thus, the _user account's_ status, in both {% data variables.product.prodname_emu %} and non-{% data variables.product.prodname_emu %} scenarios, is what's important, _not_ the user's _membership status_ in the organization where the scheduled workflow is located.
 
 ## `status`
 

assets/images/help/business-accounts/view-invoice-link.png

@@ -107,7 +107,11 @@ run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}
 
 ## `on.schedule`
 
-{% data reusables.actions.workflows.section-triggering-a-workflow-schedule %}
+You can use `on.schedule` to define a time schedule for your workflows.
+
+{% data reusables.repositories.actions-scheduled-workflow-example %}
+
+For more information about `schedule` events, see [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).
 
 ## `on.workflow_call`
 

content/actions/concepts/workflows-and-actions/notifications-for-workflow-runs.md

@@ -126,6 +126,8 @@ on:
     - cron: '*/15 * * * 1-5'
 ```
 
+For more information about `schedule` events and accepted cron syntax, see [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).
+
 ### Configuring environment variables in a pipeline
 
 #### Jenkins pipeline with an environment variable

content/actions/reference/workflows-and-actions/events-that-trigger-workflows.md

@@ -249,7 +249,7 @@ ARC supports using anonymous or authenticated proxies. If you use authenticated
 The `maxRunners` and `minRunners` properties provide you with a range of options to customize your ARC setup.
 
 > [!NOTE]
-> ARC does not support scheduled maximum and minimum configurations. You can use a cronjob or any other scheduling solution to update the configuration on a schedule.
+> ARC does not support scheduled maximum and minimum configurations. You can use a cron job or any other scheduling solution to update the configuration on a schedule.
 
 #### Example: Unbounded number of runners
 

content/actions/reference/workflows-and-actions/workflow-syntax.md

@@ -76,6 +76,7 @@ Because this restriction only applies to requests that are sent via a proxy that
 | {% data variables.product.prodname_pages %} | `github.io` | This is generally user-generated content that cannot accept data. You may not want to restrict access. |
 | {% data variables.product.prodname_github_codespaces %} | `github.dev` | To restrict access, block the endpoint entirely. |
 | SSH access | Port 22 on {% data variables.product.prodname_dotcom_the_website %} | To restrict access, block the endpoint entirely. |
+| SSH over HTTPS        | `ssh.github.com`          | To restrict access, block the endpoint entirely. |
 | {% data variables.product.github %}-hosted runners | Various | To enforce specific routing, use Azure private networking. See [AUTOTITLE](/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/about-azure-private-networking-for-github-hosted-runners-in-your-enterprise). |
 
 ### Endpoints that don't require restriction

content/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-jenkins.md

@@ -316,6 +316,8 @@ To restart streaming, click **Resume stream**.
 
 ## Enabling audit log streaming of API requests
 
+>[!NOTE] Not all API requests are included in the audit log stream after this feature is enabled. The streaming of API requests is limited to security relevant endpoints.
+
 {% data reusables.enterprise-accounts.access-enterprise %}
 {% data reusables.enterprise-accounts.settings-tab %}
 {% data reusables.enterprise-accounts.audit-log-tab %}