-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(node-project): Added ability to provide scoped private packages #1688
feat(node-project): Added ability to provide scoped private packages #1688
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1688 +/- ##
==========================================
+ Coverage 88.06% 89.94% +1.88%
==========================================
Files 132 153 +21
Lines 5109 6233 +1124
Branches 1207 1595 +388
==========================================
+ Hits 4499 5606 +1107
- Misses 610 622 +12
- Partials 0 5 +5
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! I've added a few small comments. Could you please add a section in our hand-written docs to document this feature? Just a few sentences would be great. :) Perhaps in docs/node.md
, or wherever you see most appropriate.
(This is just brainstorming, nothing that needs to be addressed): How does this experience work locally / how do you authenticate to install packages when projen isn't running in CICD? I wonder if we should also add some kind of npx projen codeartifact:auth
command, or some kind of "install hook" that allows you to specify one or more commands to run before installing dependencies in any task. Or is there a simpler way, like generating a .npmrc file, etc...
I was thinking about that too, but wanted to iterate on it with others' input. Will investigate that in future. |
Support for scoped registries is already there using the NpmRc class. Would it be possible to read this to generate the login in CICD instead of adding another way of configuring this? |
@AminFazlMondo what do you think? |
That is right, we probably could use the npmRc for the registry but the code artifact token is required for the private one, soe It is right to say that this is more to generate token in CICD pipeline. |
I think the local npmrc file option is ok if that's the correct route to go, but it still needs to have the token setup presumably as an environment variable in a workflow step. This is from the docs: https://docs.npmjs.com/using-private-packages-in-a-ci-cd-workflow#create-and-check-in-a-project-specific-npmrc-file The codeartifact-auth step in this PR currently does "npm config set" for the relevant details (registry, _authToken, always_auth), it (or a different action) could be changed to update an environment variable instead and combine that with an npmrc file (would this be auto generated/updated based on config?) https://github.com/MondoPower/codeartifact-auth/blob/main/src/index.ts Either way, I suspect most of the code in this PR is required to add a login step regardless of if it does "npm config set" or sets an env variable, so which approach seems to fit best? |
scopedPackagesOptions: this.parseScopedPackagesOptions( | ||
options.scopedPackagesOptions | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we pass in options.codeArtifactOptions so that the user doesn't have to specify the options in both scopedPackagesOptions and codeArtifactOptions ?
Managing the config via npmrc (with the |
8ebb557
to
2524cef
Compare
Hi @Chriscbr , Thanks for you feedback, after that it made us re-think the solution. |
Co-authored-by: Christopher Rybicki <crybicki98@gmail.com>
Co-authored-by: Christopher Rybicki <crybicki98@gmail.com>
Co-authored-by: Christopher Rybicki <crybicki98@gmail.com>
Co-authored-by: Charlie Hart <charlie.hart@mondo.com.au> Co-authored-by: Kevin <MondoKevin@users.noreply.github.com>
979b93e
to
d04ad7f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really great @AminFazlMondo ! I've left just a few more comments, but I think we're close to getting this merged in. 🙂
docs/node.md
Outdated
|
||
All npm packages have a name. Some package names also have a scope. A scope follows the usual rules for package names (URL-safe characters, no leading dots or underscores). When used in package names, scopes are preceded by an @ symbol and followed by a slash, e.g. `@somescope/somepackagename` | ||
|
||
This feature supports specifying options on how to access packages in each of the scopes, otherwise will try to install from default npm registry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature supports specifying options on how to access packages in each of the scopes, otherwise will try to install from default npm registry. | |
This feature supports specifying options on how package managers should access packages in each of the scopes. If no options are specified, npm or yarn will try to install scoped packages from thepublic npm registry. |
"aws-secret-access-key": secretToString( | ||
parsedCodeArtifactOptions.secretAccessKeySecret | ||
), | ||
"aws-region": "us-east-2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason this is hard-coded? Can we make it customizable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good pick up.
It's possible that a user will have multiple scopes each in a different region (and in fact account if they have access), so we need to ensure those details are passed to the ca:login script so it can generate an auth token in the correct region/account (via the --region and --domain-owner cli options) - I'll update that shortly.
However, the region you set for configure-aws-credentials can be independent of those if I'm not mistaken so long as you override it in the cli (it is a required property for that github action unfortunately ), We could grab the first repositoryurl from the array of scoped packages, parse the url and get the region from there - or we could leave it hard-coded.
I'm going to suggest we leave it hard-coded
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could obviously also add another property to set it in the options, I'm not sure if it's best/helps though?
@@ -382,6 +407,13 @@ export class NodePackage extends Component { | |||
*/ | |||
readonly codeArtifactOptions?: CodeArtifactOptions; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly, this field is being used to also provide access to Code Artifact for installing packages (not just publishing). Please update the description to reflect this
|
||
## Features | ||
|
||
### Scoped Private Packages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update this section to also explain that for the feature to work on GitHub, the user must add secrets named AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
to their repo (I believe this is true?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user can set custom secret names so long as that is passed to the codeartifact options. From there configure-aws-credentials will use the default or custom secret names that get passed along. I'll update the docs to reflect that codeartifact options are required (will that be enough to prompt users to set those secrets given it's a requirement for that?)
Co-authored-by: Christopher Rybicki <crybicki98@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks @AminFazlMondo and @charliehart-mondo :)
Currently there is no way for the packages that have some dependencies that are private to use projen. Thia allows scoped packages (eg,
@myscope
) to have different registryUrl and have code artifact login.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.