diff --git a/content/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks.md b/content/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks.md index 269a06830904..505f2dc300aa 100644 --- a/content/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks.md +++ b/content/admin/enforcing-policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks.md @@ -43,3 +43,9 @@ Due to risk of failure and performance impact for all users of your instance, we > [!NOTE] > To avoid rejection of a push due to a timeout, all combined pre-receive hooks should run in under five seconds. + +{% ifversion ghes > 3.16 %} + +{% data reusables.repositories.push-rule-and-prereceive-hooks %} + +{% endif %} diff --git a/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md b/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md index d9bb976d0a92..b0887331f962 100644 --- a/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md +++ b/content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md @@ -498,7 +498,8 @@ Each package manager **must** define a schedule interval. * Use `semiannually` to run every six months, on the first day of January and July. * Use `yearly` to run on the first day of January. * Use `cron` for cron expression based scheduling option. See [`cronjob`](#cronjob). -By default, {% data variables.product.prodname_dependabot %} randomly assigns a time to apply all the updates in the configuration file. You can use the `time` and `timezone` parameters to set a specific runtime for all intervals. + +By default, {% data variables.product.prodname_dependabot %} randomly assigns a time to apply all the updates in the configuration file. You can use the `time` and `timezone` parameters to set a specific runtime for all intervals. If you use a `cron` interval, you can define the update time with a `cronjob` expression.. ### `day` diff --git a/content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md b/content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md index b987614ee498..4915d02de528 100644 --- a/content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md +++ b/content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md @@ -75,7 +75,7 @@ When referencing a commit from a private repository inside of a commit message, ## Avoiding backlinks to linked references -By default, references generate a backlink. For example, manually linking to an issue in a pull request will automatically generate another link from the issue *back* to the pull request. +By default, references generate a backlink. For example, manually linking to an issue in a pull request will automatically generate another link from the issue _back_ to the pull request. To avoid this behavior, you can use `redirect.github.com` instead of `github.com` when constructing the URL in your reference. If you do use a `redirect.github.com` URL in your reference link, no pop-up window will appear when hovering over it. ## Further reading diff --git a/data/release-notes/enterprise-server/3-16/0.yml b/data/release-notes/enterprise-server/3-16/0.yml index ebb8dd1d1d43..eb5b434be6bf 100644 --- a/data/release-notes/enterprise-server/3-16/0.yml +++ b/data/release-notes/enterprise-server/3-16/0.yml @@ -223,8 +223,8 @@ sections: [Updated: 2025-03-19] - | - The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25] - + The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25] + closing_down: # https://github.com/github/releases/issues/4683 - | diff --git a/data/release-notes/enterprise-server/3-16/1.yml b/data/release-notes/enterprise-server/3-16/1.yml index 2db0fff0a780..da59512c75f8 100644 --- a/data/release-notes/enterprise-server/3-16/1.yml +++ b/data/release-notes/enterprise-server/3-16/1.yml @@ -73,7 +73,7 @@ sections: - | After a geo-replica is promoted to be a primary by running `ghe-repl-promote`, the actions workflow of a repository does not have any suggested workflows. - | - The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25] + The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25] errata: - | Known issues incorrectly indicated that administrators could immediately run the `/usr/local/share/enterprise/ghe-es-search-repair` script after a restore to resolve indexing and collaborator access issues. In reality, this script must be run only after the system has been up for at least one hour. [Updated: 2025-04-22] diff --git a/data/release-notes/enterprise-server/3-16/2.yml b/data/release-notes/enterprise-server/3-16/2.yml index 40ded8e3442b..436f4d0965cf 100644 --- a/data/release-notes/enterprise-server/3-16/2.yml +++ b/data/release-notes/enterprise-server/3-16/2.yml @@ -79,5 +79,4 @@ sections: - | Repository Cache Replicas return `Repository not found` when changes have been pushed to the Primary instance that have not yet synchronized to the Cache Replica. This issue can also occur in all previous patches of this release. - | - The security risk page returns a 500 error when Secret scanning is disabled. [Updated: 2025-04-25] - + The security risk page returns a 500 error when secret scanning is disabled. [Updated: 2025-04-25] diff --git a/data/reusables/repositories/push-rule-and-prereceive-hooks.md b/data/reusables/repositories/push-rule-and-prereceive-hooks.md new file mode 100644 index 000000000000..84cd9834d8ee --- /dev/null +++ b/data/reusables/repositories/push-rule-and-prereceive-hooks.md @@ -0,0 +1,12 @@ +## Choosing between push rules and pre-receive hooks +You can use push rules and pre-receive hooks to control what changes users can push to your repository. Both help you enforce policies, but they work in different ways and are designed for different use cases. + +Push rules are a built-in way to enforce common policies across repositories. You can use them to block pushes that don’t meet specific conditions, such as updates to specific files and paths, file size, or file type. +You can manage push rules through the UI or API. As they are a type of repository rulesets, push rules support audit logs, and can be used with evaluate mode to preview changes or bypassed when needed. + +Use push rules if you want to easily: + +* Enforce standard policies without writing scripts. +* Apply policies consistently across organizations and repositories. +* Manage rules through {% data variables.product.github %}'s UI and APIs. +* Use {% data variables.product.github %} native features like audit logging, bypass lists and rule insights.