jprdonnelly/docs
1
0
Fork 0
mirror of synced 2026-01-07 00:01:39 -05:00
Code Issues Projects Releases Wiki Activity

Branch was updated using the 'autoupdate branch' Actions workflow.

Browse Source
This commit is contained in:
Octomerger Bot
2021-11-11 22:00:33 -05:00
committed by GitHub
parent 0b3276bd43 99126e6c2d
commit 0185a6b14d
6 changed files with 11 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
content/admin/configuration/managing-connections-between-your-enterprise-accounts/enabling-the-dependency-graph-and-dependabot-alerts-on-your-enterprise-account.md
View File

@@ -103,7 +103,9 @@ Before enabling {% data variables.product.prodname_dependabot_alerts %} for your
{% endtip %}
{% ifversion fpt or ghec or ghes > 3.2 %}
When you enable {% data variables.product.prodname_dependabot_alerts %}, you should consider also setting up {% data variables.product.prodname_actions %} for {% data variables.product.prodname_dependabot_security_updates %}. This feature allows developers to fix vulnerabilities in their dependencies. For more information, see "[Setting up {% data variables.product.prodname_dependabot %} security and version updates on your enterprise](/admin/github-actions/enabling-github-actions-for-github-enterprise-server/setting-up-dependabot-updates)."
{% endif %}
## Viewing vulnerable dependencies on {% data variables.product.product_location %}

2
content/admin/enterprise-management/configuring-high-availability/about-geo-replication.md
View File

@@ -22,7 +22,7 @@ Geo DNS, such as [Amazon's Route 53 service](http://docs.aws.amazon.com/Route53/
## Limitations
Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes is limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. To reduce the latency and bandwidth caused by distributed teams and large CI farms without impacting write throughput, you can configure repository caching instead. For more information, see "[About repository caching](/admin/enterprise-management/caching-repositories/about-repository-caching)."
Writing requests to the replica requires sending the data to the primary and all replicas. This means that the performance of all writes is limited by the slowest replica, although new geo-replicas can seed the majority of their data from existing co-located geo-replicas, rather than from the primary. {% ifversion ghes > 3.2 %}To reduce the latency and bandwidth caused by distributed teams and large CI farms without impacting write throughput, you can configure repository caching instead. For more information, see "[About repository caching](/admin/enterprise-management/caching-repositories/about-repository-caching)."{% endif %}
Geo-replication will not add capacity to a {% data variables.product.prodname_ghe_server %} instance or solve performance issues related to insufficient CPU or memory resources. If the primary appliance is offline, active replicas will be unable to serve any read or write requests.

4
content/admin/enterprise-management/configuring-high-availability/about-high-availability-configuration.md
View File

@@ -28,8 +28,8 @@ Use a high availability configuration for protection against:
A high availability configuration is not a good solution for:
- **Scaling-out**. While you can distribute traffic geographically using geo-replication, the performance of writes is limited to the speed and availability of the primary appliance. For more information, see "[About geo-replication](/enterprise/{{ currentVersion }}/admin/guides/installation/about-geo-replication/)."
- **CI/CD load**. If you have a large number of CI clients that are geographically distant from your primary instance, you may benefit from configuring a repository cache. For more information, see "[About repository caching](/admin/enterprise-management/caching-repositories/about-repository-caching)."
- **Scaling-out**. While you can distribute traffic geographically using geo-replication, the performance of writes is limited to the speed and availability of the primary appliance. For more information, see "[About geo-replication](/enterprise/{{ currentVersion }}/admin/guides/installation/about-geo-replication/)."{% ifversion ghes > 3.2 %}
- **CI/CD load**. If you have a large number of CI clients that are geographically distant from your primary instance, you may benefit from configuring a repository cache. For more information, see "[About repository caching](/admin/enterprise-management/caching-repositories/about-repository-caching)."{% endif %}
- **Backing up your primary appliance**. A high availability replica does not replace off-site backups in your disaster recovery plan. Some forms of data corruption or loss may be replicated immediately from the primary to the replica. To ensure safe rollback to a stable past state, you must perform regular backups with historical snapshots.
- **Zero downtime upgrades**. To prevent data loss and split-brain situations in controlled promotion scenarios, place the primary appliance in maintenance mode and wait for all writes to complete before promoting the replica.

3
content/admin/github-actions/advanced-configuration-and-troubleshooting/troubleshooting-github-actions-for-your-enterprise.md
View File

@@ -149,6 +149,7 @@ If any of these services are at or near 100% CPU utilization, or the memory is n
When running `ghe-config-apply`, if you see output like `Failed to run nomad job '/etc/nomad-jobs/<name>.hcl'`, then the change has likely over-allocated CPU or memory resources. If this happens, edit the configuration files again and lower the allocated CPU or memory, then re-run `ghe-config-apply`.
1. After the configuration is applied, run `ghe-actions-check` to verify that the {% data variables.product.prodname_actions %} services are operational.
{% ifversion fpt or ghec or ghes > 3.2 %}
## Troubleshooting failures when {% data variables.product.prodname_dependabot %} triggers existing workflows
{% data reusables.dependabot.beta-security-and-version-updates %}
@@ -175,3 +176,5 @@ There are three ways to resolve this problem:
$ ghe-config-apply
```
1. Return to {% data variables.product.prodname_ghe_server %}.
{% endif %}

2
content/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/viewing-and-updating-vulnerable-dependencies-in-your-repository.md
View File

@@ -29,9 +29,11 @@ Your repository's {% data variables.product.prodname_dependabot %} alerts tab li
{% ifversion fpt or ghec or ghes > 3.2 %}
You can enable automatic security updates for any repository that uses {% data variables.product.prodname_dependabot_alerts %} and the dependency graph. For more information, see "[About {% data variables.product.prodname_dependabot_security_updates %}](/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-dependabot-security-updates)."
{% endif %}
{% data reusables.repositories.dependency-review %}
{% ifversion fpt or ghec or ghes > 3.2 %}
## About updates for vulnerable dependencies in your repository
{% data variables.product.product_name %} generates {% data variables.product.prodname_dependabot_alerts %} when we detect that your codebase is using dependencies with known vulnerabilities. For repositories where {% data variables.product.prodname_dependabot_security_updates %} are enabled, when {% data variables.product.product_name %} detects a vulnerable dependency in the default branch, {% data variables.product.prodname_dependabot %} creates a pull request to fix it. The pull request will upgrade the dependency to the minimum possible secure version needed to avoid the vulnerability.

2
data/reusables/dependabot/enterprise-enable-dependabot.md
View File

@@ -1,4 +1,4 @@
{% ifversion ghes %}
{% ifversion ghes > 3.2 %}
{% note %}