docs-bot
@@ -56,7 +56,7 @@ Use deployment branches and tags to restrict which branches and tags can deploy
|
||||
|
||||
* **Selected branches and tags:** Only branches and tags that match your specified name patterns can deploy to the environment.
|
||||
|
||||
If you specify `releases/*` as a deployment branch or tag rule, only a branch or tag whose name begins with `releases/` can deploy to the environment. (Wildcard characters will not match `/`. To match branches or tags that begin with `release/` and contain an additional single slash, use `release/*/*`.) If you add `main` as a branch rule, a branch named `main` can also deploy to the environment. For more information about syntax options for deployment branches, see the [Ruby `File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
|
||||
The deployment branch or tag rule is matched against the `GITHUB_REF` of the workflow run. For values of `GITHUB_REF` for each workflow trigger, see [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows). If you specify `releases/*` as a deployment branch or tag rule, only a `GITHUB_REF` whose name begins with `releases/` can deploy to the environment. Adding another branch rule for `refs/pull/*/merge` would also allow workflows triggered by `pull_request` events to deploy to the environment. Wildcard characters will not match `/`, to match branches or tags that begin with `release/` and contain an additional single slash, use `release/*/*`. For more information about syntax options for deployment branches, see the [Ruby `File.fnmatch` documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
|
||||
|
||||
{% data reusables.actions.branch-and-tag-deployment-rules-configuration %}
|
||||
|
||||
|
||||
@@ -125,7 +125,7 @@ If you're migrating from {% data variables.product.prodname_enterprise_backup_ut
|
||||
|
||||
Use the `--dry-run` flag to preview changes without applying them.
|
||||
|
||||
### Scheduling automated backups
|
||||
#### Scheduling automated backups
|
||||
|
||||
Once the service is configured, you can define a backup schedule.
|
||||
|
||||
@@ -134,3 +134,27 @@ Once the service is configured, you can define a backup schedule.
|
||||
1. Click **Save** to apply the changes.
|
||||
|
||||
The first run will be a full backup. Future runs will be incremental. If a new backup attempt starts while a previous one is still running, it may be skipped or fail. In that case, adjust the schedule to avoid overlap.
|
||||
|
||||
{% ifversion ghes > 3.19 %}
|
||||
|
||||
### Configuring backups from a replica node
|
||||
|
||||
For high availability, you can designate a replica node as your backup server. To minimize latency, {% data variables.product.github %} recommends picking a replica node in the same region or datacenter as your primary node.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Backups from cache replica nodes or active geo replica nodes are not supported.
|
||||
|
||||
To configure your backup server, run the following commands, replacing `HOSTNAME` with the hostname of the node:
|
||||
|
||||
```shell
|
||||
ghe-config cluster.HOSTNAME.backup-server true
|
||||
|
||||
ghe-config-apply
|
||||
```
|
||||
|
||||
You can now run `ghe-backup` directly on your replica node.
|
||||
|
||||
> [!WARNING]
|
||||
> Due to the latency between primary and replica nodes, you may lose data when backing up from a replica node.
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -31,6 +31,7 @@ If you have questions about this list, please contact us at <privacy@github.com>
|
||||
| Anthropic PBC | AI Inference and AI Services | United States | United States |
|
||||
| Cloudflare | Content delivery service | United States | United States |
|
||||
| CoreWeave, Inc. | Cloud Hosted Infrastructure | United States | United States |
|
||||
| Elasticsearch, Inc. | Cloud Hosted Infrastructure | United States | United States |
|
||||
| Fastly | Content delivery service | United States | United States |
|
||||
| Fireworks AI | AI Inference and AI Services | United States, Iceland, Germany | United States |
|
||||
| FullStory, Inc. | Customer support ticketing analysis | United States | United States |
|
||||
|
||||
@@ -46,10 +46,12 @@ To deliver webhooks to your local server for testing, you can use a webhook forw
|
||||
|
||||
## Failed to connect to host
|
||||
|
||||
The `failed to connect to host` error occurs when {% data variables.product.company_short %} attempts a webhook delivery but could not resolve the webhook's URL to an IP address.
|
||||
The `failed to connect to host` error occurs when {% data variables.product.company_short %} attempts a webhook delivery but could not resolve the webhook's URL to an IP address or there are network restrictions preventing connection to the host.
|
||||
|
||||
To check whether a host name resolves to an IP address, you can use `nslookup`. For example, if your payload URL is `https://octodex.github.com/webhooks`, you can run `nslookup octodex.github.com`. If the host name could not be resolved to an IP address, the nslookup command will indicate that the server can't find the host name.
|
||||
|
||||
You should make sure that your server allows connections from {% data variables.product.company_short %}'s IP addresses. You can use the `GET /meta` endpoint to find the current list of {% data variables.product.company_short %}'s IP addresses. See [AUTOTITLE](/rest/meta/meta#get-github-meta-information). Ensure connectivity is allowed from the IP addresses listed in the `hooks` section. {% data variables.product.company_short %} occasionally makes changes to its IP addresses, so you should update your IP allow list periodically.
|
||||
|
||||
## Failed to connect to network
|
||||
|
||||
The `failed to connect to network` error indicates that your server refused the connection when {% data variables.product.company_short %} attempted to deliver a webhook.
|
||||
|
||||
Reference in New Issue
Block a user