Hack week 2025: remove unneeded FBV instances (15) (#53990)
This commit is contained in:
mc
@@ -3,7 +3,9 @@ title: Managing accessibility settings
|
||||
shortTitle: Manage accessibility settings
|
||||
intro: '{% data variables.product.github %}''s user interface can adapt to your vision, hearing, motor, cognitive, or learning needs.'
|
||||
versions:
|
||||
feature: keyboard-shortcut-accessibility-setting
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghec: '*'
|
||||
redirect_from:
|
||||
- /account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/managing-accessibility-settings
|
||||
- /account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-personal-account-settings/managing-accessibility-settings
|
||||
|
||||
@@ -4,7 +4,9 @@ intro: 'Scripts can automatically execute on a self-hosted runner, directly befo
|
||||
redirect_from:
|
||||
- /actions/hosting-your-own-runners/running-scripts-before-or-after-a-job
|
||||
versions:
|
||||
feature: job-hooks-for-runners
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghec: '*'
|
||||
type: tutorial
|
||||
shortTitle: Run a script before or after a job
|
||||
---
|
||||
@@ -49,7 +51,7 @@ The scripts are automatically executed when the runner has the following environ
|
||||
* `ACTIONS_RUNNER_HOOK_JOB_STARTED`: The script defined in this environment variable is triggered when a job has been assigned to a runner, but before the job starts running.
|
||||
* `ACTIONS_RUNNER_HOOK_JOB_COMPLETED`: The script defined in this environment variable is triggered at the end of the job, after all the steps defined in the workflow have run.
|
||||
|
||||
To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). Note that any change to the `.env` file will require restarting the runner.
|
||||
To set these environment variables, you can either add them to the operating system, or add them to a file named `.env` within the self-hosted runner application directory (that is, the directory into which you downloaded and unpacked the runner software). Note that any change to the `.env` file will require restarting the runner.
|
||||
For example, the following `.env` entry will have the runner automatically run a script, saved as `/opt/runner/cleanup_script.sh` on the runner machine, before each job runs:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -37,12 +37,8 @@ We recommend that you schedule a maintenance window for at least 30 minutes in t
|
||||
|
||||
When the instance is in maintenance mode, all normal HTTP and Git access is refused. This includes web and API requests, for which the appliance responds with status code `503` (Service Unavailable). Git fetch, clone, and push operations are also rejected with an error message indicating that the site is temporarily unavailable.{% ifversion ghes < 3.13 %} In high availability configurations, Git replication will be paused.{% endif %} GitHub Actions jobs will not be executed. Visiting the site in a browser results in a maintenance page.
|
||||
|
||||
{% ifversion ip-exception-list %}
|
||||
|
||||
You can perform initial validation of your maintenance operation by configuring an IP exception list to allow access to {% data variables.location.product_location %} from only the IP addresses and ranges provided. Attempts to access {% data variables.location.product_location %} from IP addresses not specified on the IP exception list will receive a response consistent with those sent when the instance is in maintenance mode.
|
||||
|
||||
{% endif %}
|
||||
|
||||
## Enabling maintenance mode immediately or scheduling a maintenance window for a later time
|
||||
|
||||
{% data reusables.enterprise_site_admin_settings.access-settings %}
|
||||
@@ -56,8 +52,6 @@ You can perform initial validation of your maintenance operation by configuring
|
||||
{% data reusables.enterprise_management_console.custom-maintenance-message %}
|
||||
1. When you're satisfied with the timing of the window and the optional message, click **Save**. If you selected "now", your instance will be put into maintenance mode immediately.
|
||||
|
||||
{% ifversion ip-exception-list %}
|
||||
|
||||
## Validating changes in maintenance mode using the IP exception list
|
||||
|
||||
The IP exception list provides controlled and restricted access to {% data variables.location.product_location %}, which is ideal for initial validation of server health following a maintenance operation. Once enabled, {% data variables.location.product_location %} will be taken out of maintenance mode and available only to the configured IP addresses. The maintenance mode checkbox will be updated to reflect the change in state.
|
||||
@@ -76,8 +70,6 @@ You can also use a command-line utility to configure the IP exception list. For
|
||||
{% data reusables.enterprise_management_console.custom-maintenance-message %}
|
||||
1. Click **Save**.
|
||||
|
||||
{% endif %}
|
||||
|
||||
{% ifversion maintenance-management-api %}
|
||||
|
||||
## Managing maintenance mode using the REST API
|
||||
|
||||
@@ -180,9 +180,7 @@ $ ghe-restore -c 169.154.1.1
|
||||
> Visit https://169.154.1.1/setup/settings to review appliance configuration.
|
||||
```
|
||||
|
||||
{% ifversion ip-exception-list %}
|
||||
Optionally, to validate the restore, configure an IP exception list to allow access to a specified list of IP addresses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
|
||||
{% endif %}
|
||||
|
||||
On an instance in a high-availability configuration, after you restore to new disks on an existing or empty instance, `ghe-repl-status` may report that Git or Alambic replication is out of sync due to stale server UUIDs. These stale UUIDs can be the result of a retired node in a high-availability configuration still being present in the application database, but not in the restored replication configuration.
|
||||
|
||||
|
||||
@@ -24,7 +24,7 @@ As more users join {% data variables.location.product_location %}, you may need
|
||||
## Requirements and recommendations
|
||||
|
||||
> [!NOTE]
|
||||
> Before resizing any storage volume, put your instance in maintenance mode.{% ifversion ip-exception-list %} You can validate changes by configuring an IP exception list to allow access from specified IP addresses. {% endif %} For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
|
||||
> Before resizing any storage volume, put your instance in maintenance mode. You can validate changes by configuring an IP exception list to allow access from specified IP addresses. For more information, see [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode).
|
||||
|
||||
### Minimum recommended requirements
|
||||
|
||||
|
||||
@@ -60,9 +60,7 @@ While you can use a hotpatch to upgrade to the latest patch release within a fea
|
||||
tail -f /data/user/common/ghe-config.log
|
||||
```
|
||||
|
||||
{% ifversion ip-exception-list %}
|
||||
1. Optionally, after the upgrade, validate the upgrade by configuring an IP exception list to allow access to a specified list of IP addresses. See [AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
|
||||
{% endif %}
|
||||
1. For single node upgrades, perform any post-upgrade tasks including disabling maintenance mode so users can use {% data variables.location.product_location %}.
|
||||
|
||||
> [!NOTE] After you upgrade an instance in a high availability configuration, you should remain in maintenance mode until you have upgraded all of the replica nodes and replication is current. See [Upgrading additional nodes with an upgrade package](#upgrading-additional-nodes-with-an-upgrade-package).
|
||||
|
||||
@@ -2,7 +2,9 @@
|
||||
title: Common validation errors when creating issue forms
|
||||
intro: 'You may see some of these common validation errors when creating, saving, or viewing issue forms.'
|
||||
versions:
|
||||
feature: issue-forms
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Community
|
||||
---
|
||||
|
||||
@@ -2,7 +2,9 @@
|
||||
title: Syntax for issue forms
|
||||
intro: 'You can define different input types, validations, default assignees, and default labels for your issue forms.'
|
||||
versions:
|
||||
feature: issue-forms
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghec: '*'
|
||||
topics:
|
||||
- Community
|
||||
---
|
||||
|
||||
@@ -20,11 +20,7 @@ redirect_from:
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-issues %}
|
||||
1. In the list of issues, click the issue you'd like to close.
|
||||
{%- ifversion issue-close-reasons %}
|
||||
1. Optionally, to change your reason for closing the issue, next to "Close issue," select {% octicon "triangle-down" aria-label="Select close issue reason" %}, then click a reason.
|
||||
|
||||
|
||||
1. Click **Close issue**.
|
||||
{%- else %}
|
||||
1. At the bottom of the comment box, click **Close issue**.
|
||||
{% endif %}
|
||||
|
||||
@@ -16,7 +16,7 @@ redirect_from:
|
||||
|
||||
You can use {% data variables.product.prodname_dotcom %} repositories, issues, projects, and other tools to plan and track your work, whether working on an individual project or cross-functional team.
|
||||
|
||||
In this guide, you will learn how to create and set up a repository for collaborating with a group of people, create issue templates{% ifversion issue-forms %} and forms{% endif %}, open issues and use task lists to break down work, and establish a {% data variables.projects.projects_v1_board %} for organizing and tracking issues.
|
||||
In this guide, you will learn how to create and set up a repository for collaborating with a group of people, create issue templates and forms, open issues and use task lists to break down work, and establish a {% data variables.projects.projects_v1_board %} for organizing and tracking issues.
|
||||
|
||||
## Creating a repository
|
||||
|
||||
@@ -54,7 +54,7 @@ You can use issues to track the different types of work that your cross-function
|
||||
* Feature requests: Your team or users can create issues to request an improvement to your product or project.
|
||||
* Bugs: Your team or users can create issues to report a bug.
|
||||
|
||||
Depending on the type of repository and project you are working on, you may prioritize certain types of issues over others. Once you have identified the most common issue types for your team, you can create issue templates {% ifversion issue-forms %}and forms{% endif %} for your repository. Issue templates {% ifversion issue-forms %}and forms{% endif %} allow you to create a standardized list of templates that a contributor can choose from when they open an issue in your repository. For more information, see [AUTOTITLE](/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository).
|
||||
Depending on the type of repository and project you are working on, you may prioritize certain types of issues over others. Once you have identified the most common issue types for your team, you can create issue templates and forms for your repository. Issue templates and forms allow you to create a standardized list of templates that a contributor can choose from when they open an issue in your repository. For more information, see [AUTOTITLE](/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository).
|
||||
|
||||
### Issue template example
|
||||
|
||||
|
||||
@@ -226,8 +226,8 @@ With issue and pull request search terms, you can:
|
||||
|
||||
For issues, you can also use search to:
|
||||
|
||||
* Filter for issues that are linked to a pull request by a closing reference: `linked:pr`{% ifversion issue-close-reasons %}
|
||||
* Filter issues by the reason they were closed: `is:closed reason:completed` or `is:closed reason:"not planned"`{% endif %}
|
||||
* Filter for issues that are linked to a pull request by a closing reference: `linked:pr`
|
||||
* Filter issues by the reason they were closed: `is:closed reason:completed` or `is:closed reason:"not planned"`
|
||||
{% ifversion issue-types %}* Filter for issues with a particular type: `is:open type:"Bug"`{% endif %}
|
||||
|
||||
For pull requests, you can also use search to:
|
||||
|
||||
@@ -2,7 +2,9 @@
|
||||
title: Limiting OAuth app and GitHub App access requests
|
||||
intro: 'As an organization owner, you can choose whether to allow outside collaborators to request organization access for {% data variables.product.prodname_oauth_apps %} and {% data variables.product.prodname_github_apps %}.'
|
||||
versions:
|
||||
feature: limit-app-access-requests
|
||||
fpt: '*'
|
||||
ghes: '*'
|
||||
ghec: '*'
|
||||
permissions: Organization owners can limit who can make app access requests to the organization.
|
||||
topics:
|
||||
- Organizations
|
||||
|
||||
@@ -91,11 +91,9 @@ Optionally, you can restrict the ability to dismiss pull request reviews to spec
|
||||
|
||||
Optionally, you can choose to require reviews from code owners. If you do, any pull request that affects code with a code owner must be approved by that code owner before the pull request can be merged into the protected branch.
|
||||
|
||||
{% ifversion last-pusher-require-approval %}
|
||||
Optionally, you can require that the most recent reviewable push must be approved by someone other than the person who pushed it. This means at least one other authorized reviewer has approved any changes. For example, the "last reviewer" can check that the latest set of changes incorporates feedback from other reviews, and does not add new, unreviewed content.
|
||||
|
||||
For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.
|
||||
{% endif %}
|
||||
|
||||
{% ifversion pull-request-mergeability-security-changes %}
|
||||
{% data reusables.pull_requests.security-changes-mergeability %}
|
||||
|
||||
@@ -72,9 +72,7 @@ When you create a branch rule, the branch you specify doesn't have to exist yet
|
||||
* Optionally, to require review from a code owner when the pull request affects code that has a designated owner, select **Require review from Code Owners**. Note that if code has multiple owners, an approval from _any_ of the code owners will be sufficient to meet this requirement. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
|
||||
* Optionally, to allow specific actors to push code to the branch without creating pull requests when they're required, select **Allow specified actors to bypass required pull requests**. Then, search for and select the actors who should be allowed to skip creating a pull request.
|
||||
* Optionally, if the repository is part of an organization, select **Restrict who can dismiss pull request reviews**. Then, in the search field, search for and select the actors who are allowed to dismiss pull request reviews. For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/dismissing-a-pull-request-review).
|
||||
{% ifversion last-pusher-require-approval %}
|
||||
* Optionally, to require someone other than the last person to push to a branch to approve a pull request prior to merging, select **Require approval of the most recent reviewable push**. For more information, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging).
|
||||
{% endif %}
|
||||
1. Optionally, enable required status checks. For more information, see [AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks).
|
||||
* Select **Require status checks to pass before merging**.
|
||||
* Optionally, to ensure that pull requests are tested with the latest code on the protected branch, select **Require branches to be up to date before merging**.
|
||||
|
||||
@@ -122,11 +122,9 @@ Optionally, you can choose to dismiss stale pull request approvals when commits
|
||||
|
||||
Optionally, you can choose to require reviews from code owners. If you do, any pull request that modifies content with a code owner must be approved by that code owner before the pull request can be merged into the protected branch. Note that if code has multiple owners, an approval from _any_ of the code owners will be sufficient to meet this requirement. For more information, see [AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).
|
||||
|
||||
{% ifversion last-pusher-require-approval %}
|
||||
Optionally, you can require an approval from someone other than the last person to push to a branch before a pull request can be merged. This means at least one other authorized reviewer has approved any changes. For example, the "last reviewer" can check that the latest set of changes incorporates feedback from other reviews, and does not add new, unreviewed content.
|
||||
|
||||
For complex pull requests that require many reviews, requiring an approval from someone other than the last person to push can be a compromise that avoids the need to dismiss all stale reviews: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. Users who have already reviewed a pull request can reapprove after the most recent push to meet this requirement. If you are concerned about pull requests being "hijacked" (where unapproved content is added to approved pull requests), it is safer to dismiss stale reviews.
|
||||
{% endif %}
|
||||
|
||||
Optionally, you can require all comments on the pull request to be resolved before it can be merged to a branch. This ensures that all comments are addressed or acknowledged before merge.
|
||||
|
||||
|
||||
@@ -2,7 +2,9 @@
|
||||
title: Managing the push policy for your repository
|
||||
intro: You can limit how many branches and tags can be updated in a single push.
|
||||
versions:
|
||||
feature: limit-branches-tags-in-push
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '*'
|
||||
permissions: People with admin permissions for a repository can manage the push policy for the repository.
|
||||
topics:
|
||||
- Repositories
|
||||
|
||||
@@ -1,3 +1 @@
|
||||
{%- ifversion ip-exception-list %}
|
||||
1. Optionally, you can validate the changes by configuring an IP exception list to allow access from specified IP addresses. For more information, see [AUTOTITLE](/admin/administering-your-instance/configuring-maintenance-mode/enabling-and-scheduling-maintenance-mode#validating-changes-in-maintenance-mode-using-the-ip-exception-list).
|
||||
{%- endif %}
|
||||
|
||||
Reference in New Issue
Block a user