I have a Node.js package available in public npm repository. Also I set up a build in AWS CodeBuild to run unit tests each time there's a new push into the master branch of package's repository on github.
I'd like to set up automatic invocation of npm publish in the build specification in case if package version increases and all tests pass.
Is it possible to authenticate in npm by invoking npm add-user inside AWS CodeBuild environment without compromising my npm credentials? Right now I'm the only maintainer of the package, but I'm looking for a general solution when the package and the build are maintained by a team.
What are some best practices for handling npm credentials while dealing with AWS CodeBuild?
One way to vend credentials in general with AWS CodeBuild is "EC2 parameter store". AWS CodeBuild supports bringing Parameter Store variables as regular environment variables to your build. You can use that to vend sensitive information like npm and AWS credentials.
Documentation
https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-env-vars.html
https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html#build-spec-ref-syntax
Related
I want to do something like this:
Create an npm package. Basically, a common code which I want to use for all of my projects. Which I created.
But now What I want is, Every time I commit something in git for this project, Jenkins should build it with updated alpha/beta version and should publish to my own artifactory.
Your Jenkins job can be configured to be triggered by a webhook, which would take care of the first part (every time I commit). Depending on which Git server you're using you can find a lot of tutorials how to do that:
For GitHub
For GitLab
For Gogs
please note this is just a random selection of tutorials how to set up the webhook triggers to work with Git servers and by no means an exhaustive list
To publish your package to JFrog Artifactory you can either use the Jenkins Artifactory Plugin, or use the NPM command line. If you want to use the npm command line, you'll need to authenticate first:
# setting the default registry to Artifactory
npm config set registry http://<ARTIFACTORY_SERVER_DOMAIN>:8081/artifactory/api/npm/npm-repo/
# log in
npm login
alternatively you can get a .npmrc file directly from Artifactory using:
curl -u admin:<CREDENTIAL> http://<ARTIFACTORY_SERVER_DOMAIN>:8081/artifactory/api/npm/auth
After that, there are two ways you can push your package to Artifactory:
Edit your package.json file and add a publishConfig section to a local repository: "publishConfig":{"registry":"http://localhost:8081/artifactory/api/npm/npm-repo/"}
Provide a local repository to the npm publish command: npm publish --registry http://localhost:8081/artifactory/api/npm/npm-repo/
I'm using Artifactory to pull npm packages. One of the packages that I use is stored privately and in order to access it the publisher gave me an authentication token.
I was asked to add //registry.npmjs.org/:_authToken=<private_token> to .npmrc, however my environment use Artifactory as a proxy for the public npm registry. How can I configure an authentication token geared specifically for the package?
You can use virtual repo concept of artifactory. You can upload the custom packages into your local repo and a common repo that will get the packages from the npm
I'm trying to deploy using AWS code build and have an NPM dependency which exists in a private github repository only.
When using composer for similar scenarios I use the "github-oauth" option https://getcomposer.org/doc/06-config.md#github-oauth. Is there similar functionality for NPM without hard-coding my token into my package.json file?
We've started using Nexus OSS 3 as a standalone NPM server and so far it's working great but there's one thing that makes little sense to me, and that is the requirement to do the npm login before being able to npm install self published packages.
We're following the proposed repository structure:
npm_proxy - to use as proxy toward npm public repo
npm_private_internal - to use to upload self created internal packages
npm_private_external - to use to upload 3rd party packages
npm_group - to wrap all of them together so they're reachable with one URL
Now I understand that npm login should be required when publishing a new package, but why is it required when doing npm install of one of the self published packages, and can it be avoided ?
It's not required if you allow anonymous read privileges to your npm repositories. But I guess you've not given these privileges to the anonymous user?
If so, the alternative would be to base64 encode the needed credentials in your .npmrc file as described here:
https://books.sonatype.com/nexus-book/reference/npm-deploying-packages.html
But using npm login would be preferable.
I've setup an Nexus (2.10.0) NPM repository and administrate an user with full access to this repo.
By setting the "_auth" and "always-auth" param in my local .npmrc the publishing and reading of npm artifacts are working well. But if i try to unpublish or deprecate an npm artifact i get still an error "...This request requires auth credentials. Run npm login and repeat the request...".
What is the preferred way to remove artifacts from an nexus npm repository?
thx,
David
Unpublish is currently not supported. Details see https://issues.sonatype.org/browse/NEXUS-6892
Also keep in mind that is not considered good practice to use unpublish as you can see from the npm documentation itself linked in the issue.
Unfortunately, Nexus 2.11 doesn't support npm unpublish or npm deprecate.
If the goal is to make your previously published versions of npm-packages inaccessible:
You can delete the packages from Nexus by manually removing the tarballs from .../nexus/storage/<your_npm_repo>/<your_package>/-/ on your Nexus server and creating a scheduled task to 'rebuild hosted npm metadata':
The npm metadata for a hosted repository
can be rebuilt based on the components found in the storage of a
hosted repository. The task can serve as a recovery tool in cases
where the npm metadata database got corrupted or the component storage
was created manually or via some external process like e.g. an rsync
copying.
This also works great for injecting old versions of packages into your npm-repo. (To get these tarballs, use npm pack.)