-
Notifications
You must be signed in to change notification settings - Fork 275
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: NPM registry package for garden
#5087
base: main
Are you sure you want to change the base?
Conversation
Bumps google/cloud-sdk from `183f189` to `8663c06`. --- updated-dependencies: - dependency-name: google/cloud-sdk dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Consumers of our NPM packages won't need TS files, which are only required in the build step.
`npm publish` has no facility for publishing multiple packages at once. `lerna` gives us this capability and enables uniform version bumps across packages.
The `garden` CLI package depends on the majority of our other packages. For NPM publishing, we need to set these to non-private.
The `garden` CLI requires a `static` dir to be in proximate location to its run path. It also requires some Node options set for performance reasons. We can do both of these within the `garden` CLI shell script. By hiding these options behind an environment flag, the Pkg `garden` we currently vend is unaffected.
Co-authored-by: Steffen Neubauer <[email protected]>
This should solve for our `Error: Patch file found for package pkg which is not present at node_modules/pkg` build error.
- name: Publish stable version if normal release | ||
if: github.event.release.prerelease != true | ||
working-directory: ./core | ||
run: | | ||
npm publish | ||
lerna publish from-package --yes |
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.
Could we add some documentation how exactly the process works that increments the package version to the correct version number?
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.
@TimBeyer sure! In a code comment?
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.
I think you could leave a few short comments in here and then more detailed in https://github.com/garden-io/garden/blob/main/RELEASE_PROCESS.md
@@ -0,0 +1,16 @@ | |||
{ | |||
"$schema": "node_modules/lerna/schemas/lerna-schema.json", | |||
"version": "0.13.13", |
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.
Will this version get updated correctly with every release publishing step?
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.
Yes! lerna
can automatically bump versions according to one of a number of strategies.
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.
What I mean is, does this number here get updated and committed back or is this just a placeholder of sorts?
In the build logs, we're getting build failures due to error /home/circleci/project/node_modules/@garden-io/cli: Command failed.
Exit code: 1
Command: patch-package
Arguments:
Directory: /home/circleci/project/node_modules/@garden-io/cli
Output:
patch-package 6.5.1
Applying patches...
Error: Patch file found for package pkg which is not present at node_modules/pkg
---
patch-package finished with 1 error(s).
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Exited with code exit status 1 |
const gitDir = path.join(process.env.STATIC_DIR, '.git'); | ||
|
||
if (!fs.existsSync(gitDir)) { | ||
exec(`git init ${process.env.STATIC_DIR}`, (error, stdout, stderr) => { |
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.
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.
@stefreak, where would you move this call?
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.
I think we should finalize and merge #5120 before merging this, so we don't have to call it at all.
I'm wondering if we need to restructure things a tiny bit. Alternatively we could maybe move |
A big problem with this approach is that dependencies will not be pinned ( If we'd be using NPM, the solution would be to switch from using But Yarn does not support Using both |
Hey @stefreak and @TimBeyer thank you both for your feedback and great work in making this PR possible! I will continue working on this. I just synced with Tim and collected the steps still left before this is merge-ready. Can you both look this over and let me know if there's anything missing? Thank you!
|
What this PR does / why we need it:
This adds an NPM registry package to be published by our GitHub Actions workflow for
garden
.Which issue(s) this PR fixes:
Unblocks #4935.
Special notes for your reviewer:
There's a chicken and egg problem here you may run into when testing the GitHub Actions publish workflow, which is that the top-level
yarn && yarn build
expects these packages to exist but onlycore
is published. NPM can also derive these packages locally so it may be a non-issue but it's something to watch out for.I have tested a version of this (and you can too) by publishing the CLI package in my own NPM registry namespace. Run
npx @worldofgeese/cli
. It has been my daily driver for a week now. The difference between this and the@garden-io/cli
is thepackage.json
file. You'll notice in my test package I've stripped out a lot of@garden-io/cli
's dependencies but in this PR I've modified@garden-io/cli
directly to offer a more elegant solution. We need to test that these modifications work as well as they did in my own test package.