Repo sync

content/actions/publishing-packages/publishing-nodejs-packages.md

@@ -40,25 +40,25 @@ You may also find it helpful to have a basic understanding of the following:
 
 ## About package configuration
 
- The `name` and `version` fields in the _package.json_ file create a unique identifier that registries use to link your package to a registry. You can add a summary for the package listing page by including a `description` field in the _package.json_ file. For more information, see "[Creating a package.json file](https://docs.npmjs.com/creating-a-package-json-file)" and "[Creating Node.js modules](https://docs.npmjs.com/creating-node-js-modules)" in the npm documentation.
+ The `name` and `version` fields in the `package.json` file create a unique identifier that registries use to link your package to a registry. You can add a summary for the package listing page by including a `description` field in the `package.json` file. For more information, see "[Creating a package.json file](https://docs.npmjs.com/creating-a-package-json-file)" and "[Creating Node.js modules](https://docs.npmjs.com/creating-node-js-modules)" in the npm documentation.
 
-When a local _.npmrc_ file exists and has a `registry` value specified, the `npm publish` command uses the registry configured in the _.npmrc_ file. {% data reusables.actions.setup-node-intro %}
+When a local `.npmrc` file exists and has a `registry` value specified, the `npm publish` command uses the registry configured in the `.npmrc` file. {% data reusables.actions.setup-node-intro %}
 
 You can specify the Node.js version installed on the runner using the `setup-node` action.
 
-If you add steps in your workflow to configure the `publishConfig` fields in your _package.json_ file, you don't need to specify the registry-url using the `setup-node` action, but you will be limited to publishing the package to one registry. For more information, see "[publishConfig](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#publishconfig)" in the npm documentation.
+If you add steps in your workflow to configure the `publishConfig` fields in your `package.json` file, you don't need to specify the registry-url using the `setup-node` action, but you will be limited to publishing the package to one registry. For more information, see "[publishConfig](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#publishconfig)" in the npm documentation.
 
 ## Publishing packages to the npm registry
 
 You can trigger a workflow to publish your package every time you publish a new release. The process in the following example is executed when the release event of type `published` is triggered. If the CI tests pass, the process uploads the package to the npm registry. For more information, see "[AUTOTITLE](/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release)."
 
 To perform authenticated operations against the npm registry in your workflow, you'll need to store your npm authentication token as a secret. For example, create a repository secret called `NPM_TOKEN`. For more information, see "[AUTOTITLE](/actions/security-guides/encrypted-secrets)."
 
-By default, npm uses the `name` field of the _package.json_ file to determine the name of your published package. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `my-package` to `https://www.npmjs.com/package/my-package`.
+By default, npm uses the `name` field of the `package.json` file to determine the name of your published package. When publishing to a global namespace, you only need to include the package name. For example, you would publish a package named `my-package` to `https://www.npmjs.com/package/my-package`.
 
-If you're publishing a package that includes a scope prefix, include the scope in the name of your _package.json_ file. For example, if your npm scope prefix is "octocat" and the package name is "hello-world", the `name` in your _package.json_ file should be `@octocat/hello-world`. If your npm package uses a scope prefix and the package is public, you need to use the option `npm publish --access public`. This is an option that npm requires to prevent someone from publishing a private package unintentionally.
+If you're publishing a package that includes a scope prefix, include the scope in the name of your `package.json` file. For example, if your npm scope prefix is "octocat" and the package name is "hello-world", the `name` in your `package.json` file should be `@octocat/hello-world`. If your npm package uses a scope prefix and the package is public, you need to use the option `npm publish --access public`. This is an option that npm requires to prevent someone from publishing a private package unintentionally.
 
-This example stores the `NPM_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an _.npmrc_ file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
+This example stores the `NPM_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an `.npmrc` file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
 
 ```yaml copy
 name: Publish Package to npmjs
@@ -81,7 +81,7 @@ jobs:
           NODE_AUTH_TOKEN: {% raw %}${{ secrets.NPM_TOKEN }}{% endraw %}
 ```
 
-In the example above, the `setup-node` action creates an _.npmrc_ file on the runner with the following contents:
+In the example above, the `setup-node` action creates an `.npmrc` file on the runner with the following contents:
 
 ```ini
 //registry.npmjs.org/:_authToken=${NODE_AUTH_TOKEN}
@@ -97,9 +97,9 @@ You can trigger a workflow to publish your package every time you publish a new
 
 ### Configuring the destination repository
 
-Linking your package to {% data variables.product.prodname_registry %} using the `repository` key is optional. If you choose not to provide the `repository` key in your _package.json_ file, then {% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the _package.json_ file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If the `url` specified in the `repository` key is invalid, your package may still be published however it won't be linked to the repository source as intended.
+Linking your package to {% data variables.product.prodname_registry %} using the `repository` key is optional. If you choose not to provide the `repository` key in your `package.json` file, then {% ifversion packages-npm-v2 %}your package will not be linked to a repository when it is published, but you can choose to connect the package to a repository later.{% else %}{% data variables.product.prodname_registry %} publishes a package in the {% data variables.product.prodname_dotcom %} repository you specify in the `name` field of the `package.json` file. For example, a package named `@my-org/test` is published to the `my-org/test` {% data variables.product.prodname_dotcom %} repository. If the `url` specified in the `repository` key is invalid, your package may still be published however it won't be linked to the repository source as intended.{% endif %}
 
-If you do provide the `repository` key in your _package.json_ file, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below _package.json_ results in a package named `my-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository. Once published, only the repository source is updated, and the package doesn't inherit any permissions from the destination repository.
+If you do provide the `repository` key in your `package.json` file, then the repository in that key is used as the destination npm registry for {% data variables.product.prodname_registry %}. For example, publishing the below `package.json` results in a package named `my-package` published to the `octocat/my-other-repo` {% data variables.product.prodname_dotcom %} repository.{% ifversion packages-npm-v2 %}{% else %} Once published, only the repository source is updated, and the package doesn't inherit any permissions from the destination repository.{% endif %}
 
 ```json
 {
@@ -118,7 +118,7 @@ If you want to publish your package to a different repository, you must use a {%
 
 ### Example workflow
 
-This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an _.npmrc_ file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
+This example stores the `GITHUB_TOKEN` secret in the `NODE_AUTH_TOKEN` environment variable. When the `setup-node` action creates an `.npmrc` file, it references the token from the `NODE_AUTH_TOKEN` environment variable.
 
 ```yaml copy
 name: Publish package to GitHub Packages
@@ -146,7 +146,7 @@ jobs:
           NODE_AUTH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
 ```
 
-The `setup-node` action creates an _.npmrc_ file on the runner. When you use the `scope` input to the `setup-node` action, the _.npmrc_ file includes the scope prefix. By default, the `setup-node` action sets the scope in the _.npmrc_ file to the account that contains that workflow file.
+The `setup-node` action creates an `.npmrc` file on the runner. When you use the `scope` input to the `setup-node` action, the `.npmrc` file includes the scope prefix. By default, the `setup-node` action sets the scope in the `.npmrc` file to the account that contains that workflow file.
 
 ```ini
 //npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}

content/organizations/managing-organization-settings/creating-rulesets-for-repositories-in-your-organization.md

@@ -0,0 +1,93 @@
+---
+title: Creating rulesets for repositories in your organization
+intro: 'You can create a ruleset to target multiple repositories in your organization.'
+versions:
+  feature: repo-rules-enterprise
+permissions: 'Organization owners can create rulesets at the organization level.'
+topics:
+  - Organizations
+shortTitle: Create rulesets
+---
+
+## Introduction
+
+You can create rulesets in your organization to control how users can interact with repositories in your organization. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. You can also prevent people from renaming repositories.
+
+When you create a ruleset for an organization, you use `fnmatch` syntax to define which repositories in your organization, and which branches or tags in those repositories, are targeted by the ruleset. This provides a quicker way to target repositories in your organization than creating a separate ruleset for each repository. For more information, see "[About `fnmatch` patterns for branches, tags, and repositories](#about-fnmatch-patterns-for-branches-tags-and-repositories)."
+
+Forks do not inherit rulesets from their upstream repositories. However, forks owned by your organization are subject to the rulesets you create, like any other repository.
+
+To create a ruleset, complete the following procedures:
+
+- [Creating a branch or tag ruleset](#creating-a-branch-or-tag-ruleset)
+- [Granting bypass permissions for your ruleset](#granting-bypass-permissions-for-your-ruleset)
+- [Choosing which repositories to target in your organization](#choosing-which-repositories-to-target-in-your-organization)
+- [Choosing which branches or tags to target](#choosing-which-branches-or-tags-to-target)
+- [Selecting branch or tag protections](#selecting-branch-or-tag-protections)
+- [Adding metadata restrictions](#adding-metadata-restrictions)
+- [Finalizing your ruleset and next steps](#finalizing-your-ruleset-and-next-steps)
+
+## Creating a branch or tag ruleset
+
+{% data reusables.profile.access_org %}
+{% data reusables.profile.org_settings %}
+{% data reusables.organizations.access-ruleset-settings %}
+{% data reusables.repositories.create-ruleset-step %}
+{% data reusables.repositories.rulesets-general-step %}
+
+## Granting bypass permissions for your ruleset
+
+{% data reusables.repositories.rulesets-bypass-step %}
+
+## Choosing which repositories to target in your organization
+
+With your ruleset, you can choose to target all repositories in your organization, repositories in your organization that match a certain naming convention, or a list of manually selected repositories in your organization.
+
+If a repository is targeted by a ruleset created at the organization level, only owners of the organization can edit the ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at the organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information on creating rulesets, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
+
+### Targeting all repositories in your organization
+
+To target all repositories in your organization, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **All repositories**.
+
+### Targeting repositories by naming convention in your organization
+
+1. To target a dynamic list of repositories in your organization by naming convention, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **Dynamic list of repositories**.
+1. To begin defining a targeting pattern, in the "Targeting criteria" section, select **Add a target** {% octicon "triangle-down" aria-hidden="true" %}, then click **Include by pattern** or **Exclude by pattern**.
+1. In the modal dialog that appears, enter a repository naming pattern using `fnmatch` syntax, then click **Add Inclusion pattern** or **Add Exclusion pattern**. For more information on `fnmatch` syntax, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
+
+  {% note %}
+
+  **Note:** You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern `*cat*`, then specifically exclude a repository matching the pattern `not-a-cat`.
+
+  {% endnote %}
+
+1. Optionally, on the ruleset configuration page, select **Prevent renaming of target repositories**.
+
+### Targeting select repositories in your organization
+
+1. To target a static, manually selected list of repositories in your organization, in the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click **Select repositories**.
+1. To select repositories to target, in the "Targeting criteria" section, select {% octicon "repo" aria-hidden="true" %} **Select repositories**, then search for the name of each repository you would like to target. Select each repository from the search results.
+
+## Choosing which branches or tags to target
+
+{% data reusables.repositories.rulesets-target-branches %}
+
+## Selecting branch or tag protections
+
+{% data reusables.repositories.rulesets-protections-step %}
+
+## Adding metadata restrictions
+
+{% data reusables.repositories.rulesets-metadata-step %}
+
+## Finalizing your ruleset and next steps
+
+{% data reusables.repositories.rulesets-create-and-insights-step %}
+
+## About `fnmatch` patterns for branches, tags, and repositories
+
+{% data reusables.repositories.rulesets-fnmatch %}
+
+## About regular expressions for commit metadata
+
+{% data reusables.repositories.rulesets-commit-regex %}

content/organizations/managing-organization-settings/index.md

@@ -46,6 +46,7 @@ children:
   - /disabling-insights-for-projects-in-your-organization
   - /managing-base-permissions-for-projects
   - /allowing-project-visibility-changes-in-your-organization
+  - /creating-rulesets-for-repositories-in-your-organization
   - /managing-rulesets-for-repositories-in-your-organization
 shortTitle: Manage organization settings
 ---