search

intuit / auto

Generate releases based on semantic version labels on pull requests.
https://intuit.github.io/auto/
MIT License
2.28k stars 205 forks source link

"auto canary" in monorepo with beta version is failing #573

Closed aleclarson closed 5 years ago

aleclarson commented 5 years ago

Describe the bug

When running auto canary in a Lerna monorepo, multiple issues are appearing.

  1. The version is being bumped from 9.0.0-beta.33 to 9.0.1-canary.809.1.1a2be58f.0 when it should be 9.0.0-canary... instead.

  2. It says Error: Running command 'npx' failed right at the beginning

  3. It fails to publish to npm, saying You cannot publish over the previously published versions: 9.0.0-beta.33

The PR I'm attempting to publish is: https://github.com/react-spring/react-spring/pull/809

To Reproduce

I don't have a minimal repro yet. LMK if it's necessary.

Expected behavior

Expected all packages to be published with 9.0.0-canary.809.1.1a2be58f.0 as their version.

Desktop (please complete the following information):

Additional context

GH_TOKEN="xxx" auto canary --build 1 --pr 809
Error: Running command 'npx' failed

Changes:
 - @react-spring/addons: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/animated: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/core: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - react-spring: 9.0.0-beta.34 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/shared: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/konva: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/native: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/three: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/web: 9.0.0-beta.34 => 9.0.1-canary.809.1.1a2be58f.0
 - @react-spring/zdog: 9.0.0-beta.33 => 9.0.1-canary.809.1.1a2be58f.0

lerna notice cli v3.15.0
lerna info current version 9.0.0-beta.34
lerna WARN force-publish all packages
lerna info Assuming all packages changed
lerna WARN version Skipping working tree validation, proceed at your own risk
lerna info auto-confirmed 
lerna info execute Skipping git tag/commit
lerna info execute Skipping git push
lerna info execute Skipping releases
lerna info publish Publishing packages to npm...
lerna notice Skipping all user and access validation due to third-party registry
lerna notice Make sure you're authenticated properly ¯\_(ツ)_/¯
lerna http fetch PUT 403 https://registry.npmjs.org/@react-spring%2fshared 1475ms
lerna ERR! E403 You cannot publish over the previously published versions: 9.0.0-beta.33.

    at ChildProcess.<anonymous> (~/.nvm/versions/node/v11.10.1/pnpm-global/3/node_modules/.pnpm/registry.npmjs.org/@auto-it/core/7.6.1/node_modules/@auto-it/core/dist/utils/exec-promise.js:98:36)
    at ChildProcess.emit (events.js:197:13)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:254:12)
aleclarson commented 5 years ago

Also, the publishConfig.directory field in each package's package.json is not being respected.

hipstersmoothie commented 5 years ago

I'll take a look at this!

hipstersmoothie commented 5 years ago
  1. The version is being bumped from 9.0.0-beta.33 to 9.0.1-canary.809.1.1a2be58f.0 when it should be 9.0.0-canary... instead.

I have opened #609 to get rid of the extra hash in there. The .0 part of the version is because we the --preid flag. We need this for the rest of the version so it can't really go away.

aleclarson commented 5 years ago

@hipstersmoothie Oh I wasn't complaining about that. I just didn't want to take the time to type out the hash. 😆 That sentence is actually pointing out how it's 9.0.1 when it should be 9.0.0 still.

hipstersmoothie commented 5 years ago

Ah, I see. In that case that is expected behavior. The canary version is the simulated "next" version. For example:

PR has major label => The canary with those changes contains those major changes and should be a new major version

The reason it went to 9.0.1 is because we default to a patch when no label is found.

aleclarson commented 5 years ago

Oh ok. The latest tag currently points to 8.0.27, so I wouldn't expect auto canary to use 9.0.1 anyway. It must have been confused by the existence of 9.0.0-beta.33. Is there a way to force the version to stay at 9.0.0?

hipstersmoothie commented 5 years ago

They way it behaves right now is it will look at the "Latest Release" and you local version and use the higher one. So in this case that resolved to 9.0.0-beta.33.

Is there a way to force the version to stay at 9.0.0?

Locally if I run lerna with prerelease instead of preminor the version doesn't increment. To get prerelease to the canary command we could add an extra flag or use a prerelease label, but the feature wouldn't be automatic.

hipstersmoothie commented 5 years ago

It fails to publish to npm, saying You cannot publish over the previously published versions: 9.0.0-beta.33

This seems to be an issue around the package.jsons making their way into the dist folder. The prepare step is ran before anything auto does so the version is whatever was there at first. In this case "9.0.0-beta.33"

When lerna run its picks up this stale version of the package.json, which contains an already published version, and tries to publish again.

aleclarson commented 5 years ago

Locally if I run lerna with prerelease instead of preminor the version doesn't increment. To get prerelease to the canary command we could add an extra flag or use a prerelease label, but the feature wouldn't be automatic.

That should be good enough. Do you consider "running auto canary locally from a branch that builds off a beta/next version" to be an edge case? If not, maybe there should be automatic support here. Also, if I were to run auto canary from CI, will I still hit this edge case?

When lerna run its picks up this stale version of the package.json, which contains an already published version, and tries to publish again.

Lerna supports publishConfig.directory (see here), but maybe your integration with Lerna is somehow avoiding that code path.

hipstersmoothie commented 5 years ago

It's this line that is the problem.

Because you do this thing where you copy over the package.json, readme, etc into the dist folder and then just publish that, we need to run the prepare script at a very specific time:

  1. lerna version - changes package.json to canary version
  2. prepare - final package put in dist folder
  3. lerna publish - publishes package dist folder with correct version

So for this workflow you must let the lifecycle scripts run and ignoreScripts must be set to false (or just not at all).

hipstersmoothie commented 5 years ago

Do you consider "running auto canary locally from a branch that builds off a beta/next version" to be an edge case? If not, maybe there should be automatic support here.

beta/next support really isn't built in yet but I will come back to this issue when I try to tackle it.

hipstersmoothie commented 5 years ago

maybe your integration with Lerna is somehow avoiding that code path.

We aren't making any assumptions about the lerna usage so this shouldn't really be a problem. You can see here that we're just calling to lerna to do all the heavy lifting.

hipstersmoothie commented 5 years ago

@aleclarson I was able to publish a canary after removing ignoreScripts. I think I have addressed everything in this issue, if I have please close!

aleclarson commented 5 years ago

Okay sweet! I have a workaround in place right now, so I won't be checking anytime soon.

I'll be sure to reopen if I get around to trying this again. ;)