Merge pull request #38307 from github/repo-sync

Repo sync

Author: docs-bot

assets/images/help/issues/issues-create-saved-view.png

@@ -24,5 +24,6 @@ shortTitle: Integrate Jira with projects
 
 ## Further reading
 
-* [AUTOTITLE](/organizations/managing-organization-settings/integrating-jira-with-your-organization-project-board)
+{% ifversion projects-v1 %}
+* [AUTOTITLE](/organizations/managing-organization-settings/integrating-jira-with-your-organization-project-board){% endif %}
 * [Connect Jira Cloud to GitHub](https://confluence.atlassian.com/adminjiracloud/connect-jira-cloud-to-github-814188429.html) in the Atlassian documentation

content/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-user-account-settings/integrating-jira-with-your-personal-projects.md

@@ -42,11 +42,7 @@ There are some limits on {% data variables.product.prodname_actions %} usage whe
 > [!NOTE]
 > For self-hosted runners, different usage limits apply. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners).
 
-* **Job execution time** - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
-{% data reusables.actions.usage-workflow-run-time %}
-{% data reusables.actions.usage-api-requests %}
-* **Webhook rate limit** - Each repository is limited to 1500 events triggering a workflow run every 10 seconds. When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued.
-* **Concurrent jobs** - The number of concurrent jobs you can run in your account depends on your {% data variables.product.prodname_dotcom %} plan, as well as the type of runner used. If exceeded, any additional jobs are queued.
+For more information about service rate limits, see [AUTOTITLE](/actions/monitoring-and-troubleshooting-workflows/troubleshooting-workflows/actions-limits).
 
   **Standard {% data variables.product.prodname_dotcom %}-hosted runners**
 

content/actions/administering-github-actions/usage-limits-billing-and-administration.md

@@ -0,0 +1,50 @@
+---
+title: Actions limits
+intro: 'There are limits in {% data variables.product.prodname_actions %} which you may hit as you scale up, some may be increased by contacting support.'
+versions:
+  fpt: '*'
+  ghes: '*'
+  ghec: '*'
+shortTitle: Actions limits
+---
+
+## Limits in {% data variables.product.prodname_actions %}
+
+You be rate limited by {% data variables.product.prodname_actions %} when you scale your usage. Some limits can be increased by contacting {% data variables.contact.contact_support %}.
+
+Unless otherwise stated, the expected behaviour when a limit is reached is that the workflow/job will get cancelled.
+
+These limits are subject to change.
+
+## Existing system limits
+
+| Limit category | Limit | Threshold | Description | Can {% data variables.product.github %} Support increase? |
+| :---- | :---- | :---- | :---- | :---- |
+| Workflow execution limit | Workflow run time | 35 days / workflow run | If a workflow run reaches this limit, the workflow run is cancelled. This period includes execution duration, and time spent on waiting and approval. | {% octicon "x" aria-label="No" %} |
+| Workflow execution limit | Gate approval time | 30 days | A workflow may wait for up to [30 days on environment approvals](/actions/managing-workflow-runs-and-deployments/managing-deployments/managing-environments-for-deployment#wait-timer). | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Workflow trigger event rate limit | 1500 events / 10 seconds / repository | Each repository is limited to events triggering a workflow run. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Workflows queuing | Workflow run queued | 500 workflow runs / 10 seconds | When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued. Reusable workflows are viewed as a single entity. For example, a run with 30 reusable workflows counts as 1 in this instance. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Workflow run start | 50 workflow runs / minute | When the limit is reached, additional workflow runs will queue, causing delays in starting jobs. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Workflows execution | Job assignment | 100 jobs / minute / repo | When the limit is reached, additional jobs will queue, causing delays in starting jobs and updating the UI results of existing jobs. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Workflow execution | Job Matrix | 256 jobs / workflow run | A job matrix can generate a maximum of jobs per workflow run. This limit applies to both {% data variables.product.github %}-hosted and self-hosted runners. | {% octicon "x" aria-label="No" %} |
+| Self-hosted | Runner registrations | 1500 runners / 5 minutes / repository/org/enterprise | Runners can be registered per repository/organization/enterprise. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Self-hosted | Runners per runner group | 10,000 runners | Runners registered at the same time per runner group. | {% octicon "x" aria-label="No" %} |
+| Hosted-runners | Job Concurrency | Varies | For more information about concurrency limits for standard and larger runners, see [AUTOTITLE](/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits). | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Hosted-runners | Job execution time | 6 hours | Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails. | {% octicon "x" aria-label="No" %} |
+| {% ifversion fpt or ghec %} |
+| Hosted-runners | Storage limits | Varies | For more information, see [AUTOTITLE](/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions#included-storage-and-minutes). | {% octicon "x" aria-label="No" %} |
+| {% endif %} |
+| Larger runners | Per runner concurrency limit | Varies by runner type | You establish when setting up a runner, normally 1,000 max for Linux CPU runners but varies by type. For more information, see [AUTOTITLE](/actions/administering-github-actions/usage-limits-billing-and-administration#usage-limits). | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Larger runners | Static IP limits | 10-50 IPs | 10 IPs for team plans, 50 IPs for enterprise, and the limit is configurable. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Larger runners | Private IP scaling for vnet injection | 30% buffer | You need to determine the appropriate subnet IP address range, for which we recommend adding a buffer to the maximum job concurrency you anticipate. For instance, if the network configuration's runners are set to a maximum job concurrency of 300, utilize a subnet IP address range that can accommodate at least 390 runners. Note that Azure reserves 5 IPs in every subnet (first 4 and last 1), which sets a minimum practical subnet size depending on runner requirements. Very small subnets (like /29 or smaller) may not provide enough usable addresses for your needs. | {% octicon "check" aria-label="Yes" %} \- Configurable Azure virtual network |
+
+### Commonly hit dependent service limits
+
+{% data variables.product.github %}'s [REST API rate limits](/rest/using-the-rest-api/rate-limits-for-the-rest-api) apply to {% data variables.product.prodname_actions %} users, those that are commonly hit are:
+
+* **Unauthenticated users** \- {% data reusables.rest-api.primary-rate-limit-unauthenticated-users %}
+* **Authenticated users** \- {% data reusables.rest-api.primary-rate-limit-authenticated-users %}
+* **GitHub app installations** \- {% data reusables.rest-api.primary-rate-limit-github-app-installations %}
+* **OAuth apps \-** {% data reusables.rest-api.primary-rate-limit-oauth-apps %}
+* **GITHUB TOKEN** \- {% data reusables.rest-api.primary-rate-limit-github-token-in-actions %}
+* **Secondary rate limits** \- In addition to primary rate limits, {% data variables.product.github %} enforces secondary rate limits in order to prevent abuse and keep the API available for all users, these are not configurable with GHEC. For more information, see [AUTOTITLE](/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits).

content/actions/monitoring-and-troubleshooting-workflows/troubleshooting-workflows/actions-limits.md

@@ -8,6 +8,7 @@ versions:
   ghec: '*'
 children:
   - /about-troubleshooting-workflows
+  - /actions-limits
   - /using-copilot-to-troubleshoot-workflows
   - /enabling-debug-logging
   - /working-with-support-for-github-actions

content/actions/monitoring-and-troubleshooting-workflows/troubleshooting-workflows/index.md

@@ -52,6 +52,7 @@ If you run analysis in an external CI system, we recommend using the same versio
 
 | {% data variables.product.prodname_ghe_server %} version | Recommended {% data variables.product.prodname_codeql_cli %} version |
 | ------------------------------------------------- | ---------------------- |
+| 3.17 | 2.20.7 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.7/)) |
 | 3.16 | 2.20.3 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.20.3/)) |
 | 3.15 | 2.18.4 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.18.4/)) |
 | 3.14 | 2.17.6 ([changelog](https://codeql.github.com/docs/codeql-overview/codeql-changelog/codeql-cli-2.17.6/)) |
@@ -70,6 +71,7 @@ For instances with {% data variables.product.prodname_actions %} enabled, self-h
 
 | {% data variables.product.prodname_ghe_server %} version | Minimum Runner version |
 | ------------------------------------------------- | ---------------------- |
+| 3.17 | 2.322.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.322.0)) |
 | 3.16 | 2.321.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.321.0)) |
 | 3.15 | 2.319.1 ([release notes](https://github.com/actions/runner/releases/tag/v2.319.1)) |
 | 3.14 | 2.317.0 ([release notes](https://github.com/actions/runner/releases/tag/v2.317.0)) |

content/admin/all-releases.md

@@ -0,0 +1,54 @@
+---
+title: About the backup service for GitHub Enterprise Server
+shortTitle: About the backup service
+intro: 'Learn what the built-in backup service offers and how it differs from a High Availability replica.'
+versions:
+  ghes: '>=3.17'
+type: overview
+topics:
+  - Backups
+  - Enterprise
+  - Fundamentals
+  - Infrastructure
+---
+
+>[!NOTE] {% data variables.product.prodname_enterprise_backup_service %} is currently in {% data variables.release-phases.public_preview %} and is subject to change. During the public preview, the service is available at no additional cost.
+
+## About the {% data variables.product.prodname_enterprise_backup_service %}
+
+The {% data variables.product.prodname_enterprise_backup_service %} is a managed backup solution built directly into {% data variables.product.prodname_ghe_server %}. It offers a simplified alternative to the legacy {% data variables.product.prodname_enterprise_backup_utilities %}.
+
+With this service, you can:
+
+* Configure scheduled backups from the {% data variables.enterprise.management_console %}.
+* View backup status and history.
+
+Compared to the legacy backup utilities, the {% data variables.product.prodname_enterprise_backup_service %}:
+
+* Can be configured through the {% data variables.enterprise.management_console %}.
+* Doesn’t require a separate host for backup software.
+* Stores backups on a dedicated storage volume directly accessible by your instance.
+
+>[!NOTE] {% data variables.product.prodname_enterprise_backup_service %} is currently only supported on standalone instances and high availability primary nodes. Cluster configurations and replica nodes are not yet supported.
+
+## How does the backup service differ from a High Availability replica?
+
+While both the backup service and a High Availability (HA) replica contribute to data protection, they serve different purposes and are recommended together for a robust deployment.
+
+### High Availability replica
+
+An HA replica is a redundant, passive {% data variables.product.prodname_ghe_server %} instance that stays in sync with the primary instance via datastore replication. It minimizes service disruption during hardware failure or network outages.
+
+However, it’s not a replacement for backups—because any data corruption or loss on the primary can be immediately replicated to the HA node.
+
+### {% data variables.product.prodname_enterprise_backup_service %}
+
+The backup service is a disaster recovery solution. It captures full, timestamped snapshots of instance data that can be used to restore an instance or spin up a new one—without needing an always-on replica.
+
+## Further reading
+
+* [AUTOTITLE](/admin/backing-up-and-restoring-your-instance/configuring-backups-on-your-instance)
+* [About {% data variables.product.prodname_enterprise_backup_utilities %}](https://github.com/github/backup-utils#readme)
+* [AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)
+* [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)
+* [AUTOTITLE](/admin/github-actions/advanced-configuration-and-troubleshooting/backing-up-and-restoring-github-enterprise-server-with-github-actions-enabled)

content/admin/backing-up-and-restoring-your-instance/backup-service-for-github-enterprise-server/about-the-backup-service-for-github-enterprise-server.md

@@ -0,0 +1,46 @@
+---
+title: Backup service settings reference
+shortTitle: Backup settings
+intro: 'Reference for all configurable options available in the Backup Service section of the {% data variables.enterprise.management_console %}.'
+versions:
+  ghes: '>= 3.17'
+type: reference
+topics:
+  - Backups
+---
+
+You can configure the following options in the "Backup Service" section of the {% data variables.enterprise.management_console %}.
+
+## Snapshot retention
+
+* **Number of snapshots**: Sets how many backup snapshots to retain (default: `10`). Older snapshots are automatically pruned after each successful backup.
+
+## Restore options
+
+* **Skip audit logs restore**: Excludes audit logs during a restore.
+* **Restore Management Console password**: If enabled, restores the root site admin password from snapshot data (default: `true`).
+
+## Performance tuning
+
+* **Process priority**:
+
+  * **Nice**: Sets the CPU scheduling priority (`nice -n 19` by default).
+  * **Ionice**: Sets the I/O scheduling priority (`ionice -c 3` by default).
+
+* **Rsync compression**: Uses compression for `rsync` transfers during backup and restore, reducing bandwidth usage.
+
+## MSSQL backup schedule
+
+* **MSSQL backup cadence**: Sets the schedule for full, differential, and transaction log backups, in minutes (default: `10080,1440,15`).
+
+## Backup content
+
+* **Include Pages**: Adds {% data variables.product.prodname_pages %} data to snapshots.
+* **Skip search indices**: Excludes search index data from snapshots.
+
+## Parallelization settings
+
+* **Enable parallel jobs**: Allows multiple backup jobs to run concurrently.
+* **Max jobs**: Limits the total number of parallel backup jobs.
+* **Max rsync jobs**: Limits the number of parallel `rsync` jobs.
+* **Max system load**: Sets a load limit to throttle parallel processing when needed.