diff --git a/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md b/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md index e5fc94f31f5c..9247f356e61b 100644 --- a/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md +++ b/content/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows.md @@ -838,7 +838,7 @@ jobs: > The webhook payload available to GitHub Actions does not include the `added`, `removed`, and `modified` attributes in the `commit` object. You can retrieve the full commit object using the API. For information, see "[AUTOTITLE](/graphql/reference/objects#commit)" in the GraphQL API documentation or "[AUTOTITLE](/rest/commits#get-a-commit)." > [!NOTE] -> {% ifversion fpt or ghec or ghes > 3.13 %}Events will not be created if more than 5,000 branches are pushed at once. {% endif %}Events will not be created for tags when more than three tags are pushed at once. +> {% ifversion fpt or ghec or ghes > 3.14 %}Events will not be created if more than 5,000 branches are pushed at once. {% endif %}Events will not be created for tags when more than three tags are pushed at once. Runs your workflow when you push a commit or tag, or when you create a repository from a template. diff --git a/content/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line.md b/content/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line.md index e1e7f9dc1e9f..cb5c0eb6b634 100644 --- a/content/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line.md +++ b/content/code-security/secret-scanning/working-with-secret-scanning-and-push-protection/working-with-push-protection-from-the-command-line.md @@ -107,7 +107,12 @@ You can also remove the secret if the secret appears in an earlier commit in the 1. Save and close the editor to start the interactive rebase. 1. Remove the secret from your code. -1. Add your changes to the staging area using `git add .` +1. Add your changes to the staging area using `git add .`. + + >[!NOTE] The full command is `git add .`: + > * There is a space between `add` and `.`. + > * The period following the space is part of the command. + 1. Commit your changes using `git commit --amend`. 1. Run `git rebase --continue` to finish the rebase. 1. Push your changes with `git push`. diff --git a/content/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles.md b/content/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles.md index c5907d60feb5..2e644b046b46 100644 --- a/content/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles.md +++ b/content/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles.md @@ -1,6 +1,6 @@ --- title: About custom organization roles -intro: "You can control access to your {% ifversion org-custom-role-with-repo-permissions %}organization and repository's{% else %} organization's{% endif %} settings with custom organization roles." +intro: "You can control access to your {% ifversion org-custom-role-with-repo-permissions %}organization's settings and repositories{% else %}organization's settings{% endif %} with custom organization roles." versions: feature: 'custom-org-roles' topics: @@ -16,9 +16,14 @@ You can create and assign custom organization roles in your organization's setti {% ifversion org-custom-role-with-repo-permissions %} -You can also create a custom organization role that includes permissions for repositories. Repository permissions grant access to all current and future repositories in the organization. There are several ways to combine permissions for repositories and organizations. You can create a custom organization role with: +You can also create a custom organization role that includes permissions for repositories. Repository permissions grant access to all current and future repositories in the organization. -You can create a role that includes permissions for organization settings, a base role for repository access, or both. If you add a base role for repository access, you can also include additional repository permissions. You can't create a role with repository permissions unless it includes a base repository role. Without repository permissions or a base repository role, the organization role doesn't grant access to any repositories. +There are several ways to combine permissions for repositories and organizations. + +* You can create a role that includes permissions for organization settings, a base role for repository access, or both. +* If you add a base role for repository access, you can also include additional repository permissions. You can't add repository permissions without a base repository role. + +Without repository permissions or a base repository role, the organization role doesn't grant access to any repositories. >[!NOTE] Adding repository permissions to a custom organization role is currently in {% data variables.release-phases.public_preview %} and subject to change. diff --git a/data/release-notes/enterprise-server/3-14/0.yml b/data/release-notes/enterprise-server/3-14/0.yml index aebcfe34f7a9..f7e1af5654c2 100644 --- a/data/release-notes/enterprise-server/3-14/0.yml +++ b/data/release-notes/enterprise-server/3-14/0.yml @@ -168,11 +168,6 @@ sections: - | When using a JSON Web Token (JWT) to authenticate or request an installation token, developers of GitHub Apps can use the app's client ID for the JWT's `iss` claim. The application ID remains valid, but is considered deprecated. - changes: - # https://github.com/github/releases/issues/3927 - - | - Pushes that update over 5,000 branches no longer trigger webhooks or GitHub Actions workflows. - known_issues: - | Complete SCIM payloads are written to the audit log, including SCIM attributes that are not required or supported per [API docs](/rest/enterprise-admin/scim?apiVersion=2022-11-28#supported-scim-user-attributes). Customers using Okta with SCIM may notice that a placeholder password attribute is among the data passed to audit logs in its current configuration. This placeholder data is associated with Okta’s password synchronization feature that is not expected or required by GitHub. See [okta-scim](https://developer.okta.com/docs/api/openapi/okta-scim/guides/scim-20/#create-the-user) for more information. @@ -233,3 +228,5 @@ sections: The fix for this problem was already included prior to the release of GitHub Enterprise Server 3.14.0. [Updated: 2024-09-16] - | These release notes did not include a note for support of the `directories` key in `dependabot.yml` files. [Updated: 2024-10-07] + - | + The "Changes" section indicated that "Pushes that update over 5,000 branches no longer trigger webhooks or GitHub Actions workflows." The change instead affects GitHub Enterprise Server version 3.15. [Updated: 2024-10-30] diff --git a/data/reusables/organizations/pre-defined-organization-roles.md b/data/reusables/organizations/pre-defined-organization-roles.md index 232a4d31d2ac..d608e5d29bda 100644 --- a/data/reusables/organizations/pre-defined-organization-roles.md +++ b/data/reusables/organizations/pre-defined-organization-roles.md @@ -1,4 +1,4 @@ -Pre-defined organization roles are roles that are available by default in every organization - no need to create them yourself. They can include both organization permissions that let the recipient manage the organization, as well as repository permissions that apply to all of the repositories in the organization. The following pre-defined roles are built into every organization based on common patterns of permissions organizations usually need. +Pre-defined organization roles are roles that are available by default in every organization. You don't need to create them yourself. They can include both organization permissions that let the recipient manage the organization, as well as repository permissions that apply to all of the repositories in the organization. The following pre-defined roles are built into every organization based on common patterns of permissions organizations usually need. The current set of pre-defined roles are: @@ -7,4 +7,6 @@ The current set of pre-defined roles are: * **All-repository triage**: Grants triage access to all repositories in the organization. * **All-repository maintain**: Grants maintenance access to all repositories in the organization. * **All-repository admin**: Grants admin access to all repositories in the organization. +{%- ifversion ghes > 3.15 %} * **CI/CD admin**: Grants admin access to manage Actions policies, runners, runner groups, hosted compute network configurations, secrets, variables, and usage metrics for an organization. +{%- endif %}