You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/actions/publishing-packages/publishing-nodejs-packages.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,9 +55,9 @@ You can trigger a workflow to publish your package every time you publish a new
55
55
56
56
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)."
57
57
58
-
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 `npm-hello-world-test` to `https://www.npmjs.com/package/npm-hello-world-test`.
58
+
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`.
59
59
60
-
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.
60
+
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.
61
61
62
62
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.
63
63
@@ -100,11 +100,11 @@ You can trigger a workflow to publish your package every time you publish a new
100
100
101
101
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.
102
102
103
-
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-amazing-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.
103
+
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.
For example, if you're the user `monalisa` and own `my-repo`, and {% data variables.location.product_location %} hostname is `github.companyname.com`, you would add this line to your Dockerfile:
41
+
For example, if you're the user `octocat` and own `my-repo`{% ifversion ghes > 3.4 %}, and your {% data variables.location.product_location %} hostname is `github.companyname.com`,{% endif %} you would add this line to your Dockerfile:
42
42
```shell
43
-
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/monalisa/my-repo
43
+
LABEL org.opencontainers.image.source=https://{% ifversion fpt or ghec %}github.com{% else %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/my-repo
44
44
```
45
45
For more information, see "[LABEL](https://docs.docker.com/engine/reference/builder/#label)" in the official Docker documentation and "[Pre-defined Annotation Keys](https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys)" in the `opencontainers/image-spec` repository.
46
46
@@ -49,16 +49,17 @@ When you publish a package that is scoped to a personal account or an organizati
49
49
```shell
50
50
$ docker build -t hello_docker .
51
51
```
52
-
3. Optionally, review details for the Docker image you want to tag.
52
+
53
+
3. Optionally, review the details of the Docker image you just created.
53
54
```shell
54
55
$ docker images
55
-
> REPOSITORY TAG IMAGE ID CREATED SIZE
56
-
>{% data reusables.package_registry.container-registry-example-hostname %}/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
57
-
>{% data reusables.package_registry.container-registry-example-hostname %}/my-username/hello_dockerlatest38f737a91f39 47 hours ago 91.7MB
58
-
>hello-worldlatest fce289e99eb9 16 months ago 1.84kB
56
+
> REPOSITORY TAG IMAGE ID CREATED SIZE
57
+
> hello_docker latest 142e665b1faa5 seconds ago 125MB
58
+
>redis latestafb5e116cac03 months ago 111MB
59
+
>alpine latest a6215f2719585 months ago 5.29MB
59
60
```
60
61
61
-
4.Tag your Docker image with your desired image name and hosting destination.
62
+
4.Assign a name and hosting destination to your Docker image.
62
63
```shell
63
64
$ docker tag IMAGE_NAME {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/NEW_IMAGE_NAME:TAG
64
65
```
@@ -67,7 +68,7 @@ When you publish a package that is scoped to a personal account or an organizati
67
68
68
69
For example:
69
70
```shell
70
-
$ docker tag 38f737a91f39 {% data reusables.package_registry.container-registry-example-hostname %}/monalisa/hello_docker:latest
71
+
$ docker tag 38f737a91f39 {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
71
72
```
72
73
73
74
5. If you haven't already, authenticate to the {% data variables.product.prodname_container_registry %}. For more information, see "[AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry)."
@@ -83,6 +84,6 @@ When you publish a package that is scoped to a personal account or an organizati
83
84
```
84
85
For example:
85
86
```shell
86
-
$ docker push {% data reusables.package_registry.container-registry-example-hostname %}/monalisa/hello_docker:latest
87
+
$ docker push {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
Copy file name to clipboardExpand all lines: content/packages/learn-github-packages/deleting-and-restoring-a-package.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -190,7 +190,7 @@ You can restore a deleted package or version if:
190
190
- You restore the package within 30 days of its deletion.
191
191
- The same package namespace and version is still available and not reused for a new package.
192
192
193
-
For example, if youhave a deleted RubyGems package named `octo-package` that was scoped to the repo `octo-repo-owner/octo-repo`, then you can only restore the package if the package namespace `rubygem.pkg.github.com/octo-repo-owner/octo-repo/octo-package` is still available, and 30 days have not yet passed.
193
+
For example, if you're the user `octocat`, and you have a deleted RubyGems package named `my-package` that was scoped to the repo `octocat/my-repo`, then you can only restore the package if the package namespace `rubygem.pkg.github.com/octocat/my-repo/my-package` is still available, and 30 days have not yet passed.
194
194
195
195
{% ifversion fpt or ghec %}
196
196
To restore a deleted package, you must also meet one of these permission requirements:
> Status: Downloaded newer image for {% data reusables.package_registry.container-registry-hostname %}/user/image-name:latest
131
-
> {% data reusables.package_registry.container-registry-hostname %}/user/image-name:latest
130
+
> Status: Downloaded newer image for {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
131
+
> {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
132
132
```
133
133
134
134
Replace `NAMESPACE` with the name of the personal account or organization to which the image is scoped.
@@ -146,8 +146,7 @@ This example builds the `hello_docker` image:
146
146
```shell
147
147
$ docker images
148
148
> REPOSITORY TAG IMAGE ID CREATED SIZE
149
-
> {% data reusables.package_registry.container-registry-hostname %}/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
150
-
> {% data reusables.package_registry.container-registry-hostname %}/my-username/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
149
+
> {% data reusables.package_registry.container-registry-hostname %}/my-org/hello_docker latest 38f737a91f39 47 hours ago 91.7MB
151
150
> hello-world latest fce289e99eb9 16 months ago 1.84kB
152
151
```
153
152
@@ -174,10 +173,10 @@ Key | Description
174
173
| `org.opencontainers.image.description` | A text-only description limited to 512 characters. This description will appear on the package page, below the name of the package.
175
174
| `org.opencontainers.image.licenses` | An SPDX license identifier such as "MIT," limited to 256 characters. The license will appear on the package page, in the "Details" sidebar. For more information, see [SPDX License List](https://spdx.org/licenses/).
176
175
177
-
To add a key as a Docker label, we recommend using the `LABEL` instruction in your `Dockerfile`. For example, if you're the user `monalisa` and you own `my-repo`, and your image is distributed under the terms of the MIT license, you would add the following lines to your `Dockerfile`:
176
+
To add a key as a Docker label, we recommend using the `LABEL` instruction in your `Dockerfile`. For example, if you're the user `octocat` and you own `my-repo`, and your image is distributed under the terms of the MIT license, you would add the following lines to your `Dockerfile`:
0 commit comments