`changeset git-tag` in a step after `version` silently creates no tags after v1 -> v2 upgrade

[aevv]

Problem

After updating from v1 to v2, running npx changeset git-tag in a step after npm run version fails to add a tag, without reporting an error. @changeset/git's tag() runs git tag <name> -m <name> which requires a committer identity, which was previously set unconditionally but is now conditional. Result is any following actions relying on the tag will fail.

The problem is two-fold: not adding the tag, and incorrectly successfully reporting the tag was added.

🦋 changeset v3.0.3
◇  Created git tags:
- v4.3.0
Everything up-to-date                      ← git push origin --tags had nothing to push

Reproduction

Workflow, previously on changesets/action@v1 + CLI v2, migrated per the v2 notes:

- uses: changesets/action@v2
  id: changesets
  with:
    pr-title: 'New Release'
    commit-message: 'Release new version'
    version-script: npm run version
    github-token: ${{ secrets.GITHUB_TOKEN }}

- if: steps.changesets.outputs.has-changesets == 'false'
  run: |
    npx changeset git-tag && git push origin --tags
    COMMIT_TAG=$(git tag --points-at HEAD)
    # ... create release, publish, when COMMIT_TAG is non-empty

Identity requirement, on a runner with no user.name/user.email:

$ git tag v1            # lightweight
$ echo $?
0
$ git tag v2 -m v2      # annotated
*** Please tell me who you are.
fatal: empty ident name (for <>) not allowed
$ echo $?
128

Workaround

Manually configure an identity for the workflow in an earlier step, matching the identity changesets was setting.

- name: Configure git identity
  run: |
    git config user.name 'github-actions[bot]'
    git config user.email '41898282+github-actions[bot]@users.noreply.github.com'

[bluwy]

The workaround is the solution if you're migrating to v2. We no longer add a fallback user name and email unless the action needs to make a local commit or tag. We also don't make the local commit or tag by default as we use the GitHub API instead.

Relevant part of the changelog:

• Remove the setup-git-user input. Complete custom Git identities are now preserved automatically, while github-actions[bot] is configured as a fallback before creating local release commits or tags.

• Release commits and tags are now pushed using the GitHub API by default.

  Replace the commit-mode input with the boolean push-with-git-cli input. Set push-with-git-cli: true to continue using the Git CLI.

So to work with this, configure the git user name and email yourself, or set push-with-git-cli: true for the action to use local git and it'd set the same user name and email as fallback internally (and can be reused for your later commands)

[beeequeue]

can we make the git tag creation report that it failed in this case? that would prevent confusion about what the problem is

[bluwy]

Yeah I think we have issues (or at least several places) where our git operations aren't handling errors right in the core repo