[Q or Feature Request] Need to bump version separately from `shipit` - currently get double bump about auto HOT 9 OPEN

I think this is more or less the same ask as in #1965

from auto.

Thanks @laughedelic, it looks like auto shipit --dry-run --quiet can resolve the deterministic version, so the only question would be how to get shipit to allow the arg version to be specified instead of resolved.

It is a similar issue in that I don't want to replicate logic to call latest(), canary() etc. As-is if I called latest it would still double bump (that's what it is doing behind the scenes).

from auto.

I'm definitely open to the arg being added to shipit. Makes sense to me. That logic might break down for indepenently versioned monorepos but a lot of other stuff does too. Happy to accept a PR here.

from auto.

It looks like publishFullRelease() already accepts {useVersion} to override, but that is not used for canary|next functions. I'm still familiarizing myself with the code but it may be as simple as exposing that for latest().

from auto.

It looks like (from auto.ts) that shipit, release and latest() allow --use-version as an option, though I think the behavior is not necessarily well defined as it is only included in the docs for release (I'm still perusing). Since shipit may call canary|next|latest|oldRelease() it might be important to clarify. It seems to me the right way to implement it is to document it, and expose it in each of the public commands. Does this sound like a reasonable implementation path @hipstersmoothie?

  {
    name: "shipit",
    group: "Release Commands",
    description: endent`
      Context aware publishing.

      1. call from base branch -> latest version released (LATEST)
      2. call from prerelease branch -> prerelease version released (NEXT)
      3. call from PR in CI -> canary version released (CANARY)
      4. call locally when not on base/prerelease branch -> canary version released (CANARY)
    `,
    examples: ["{green $} auto shipit"],
    options: [
      ...latestCommandArgs,
      {
        ...useVersion,
        description: `${useVersion.description} Currently only supported for the **npm plugin**.`,
      },

Implement useVersion for:

• latest
• canary
• next
• shipit (exposed option not documented)
• release (done already)
• oldRelease

from auto.

useVersion || bump (effectively) is in a lot of places. I suggest in the implementation this gets resolved early in each of the public interfaces and is taken as-is, instead of this-or-that in many places.

One of many:

      await this.hooks.publish.promise({
        bump,
        useVersion: options.useVersion,
      });

Why not resolve this once as bump and ignore useVersion beyond the public interface? I suggest consolidated resolution of the deterministic bump should be had at the public interface and propagated as resolved to the plugins (not as two options).

Answer: it appears bump is a kind like patch whereas useVersion is an actual version override.

from auto.

Ok, so while this is not documented for shipit, --use-version does exist.

It appears that I can get satisfactory results as-is (npm plugin) with:

1. Determine what shipit would use beforehand with yarn auto shipit --dry-run --quiet
2. Instruct shipit to use a specific version yarn auto shipit --use-version 20.0.0

I'll try this path and see how it goes.

from auto.

So I did get this to work with the existing code, though it is a bit of a workaround.

Here is how it worked:

First, get the shipit version and bump it with lerna:

      # start release here so that builds uses the correct version
      - run: yarn autoBumpVersion --verbose
      - run: ./node_modules/.bin/appVersion --verbose
      - run: yarn auto info

NOTE: autoBumpVersion is our own encapsulation of capturing version from auto shipit --dry-run --quiet output and using that as input to lerna version <version> --yes --no-git-tag-version --no-push

NOTE 2: appVersion is our own script to grab the version from lerna.json (in production conditions, it does other things in dev)

Second, do my intermediate things like build apps/tag images, etc.

Third, manipulate some conditions and shipit:

      - run:
          name: shipit
          # 1. Capture the bumped version
          # 2. Stash the lerna.json to allow shipit to modify/commit it (so that git commit inside shipit succeeds without erroring on zero changes)
          # 3. Commit the rest of the previously bumped changes
          # 4. Shipit
          command: |
            export USE_VERSION=`./node_modules/.bin/appVersion`
            git stash push lerna.json
            yarn autoCommitDiff --verbose
            yarn auto shipit --use-version $USE_VERSION

NOTE: autoCommitDiff is our own script that just does some logging and commits diffs from version bump changes in the very first part of the multi-stage build.

So, the only oddity here is that I have to specifically stash a file (any file that will get modified) so that shipit's execution of git commit doesn't report non-zero and fail.

So, this issue could be closed, I'm satisfied enough to move on, or it could be left open knowing that it could be perhaps better specified/documented. It's up to the maintainers to decide.

from auto.