Always try to push invalid tags

[Jack-Works]

🦋  info @masknet/compartment is being published because our local version (0.2.2) has not been published on npm
🦋  warn @masknet/intrinsic-snapshot is not being published because version 0.1.0 is already published on npm
🦋  info @masknet/static-module-record-swc is being published because our local version (0.3.1) has not been published on npm
🦋  info Publishing "@masknet/compartment" at "0.2.2"
🦋  info Publishing "@masknet/static-module-record-swc" at "0.3.1"
🦋  success packages published successfully:
🦋  @masknet/compartment@0.2.2
🦋  @masknet/static-module-record-swc@0.3.1
🦋  Creating git tags...
🦋  New tag:  @masknet/compartment@0.2.2
🦋  New tag:  @masknet/static-module-record-swc@0.3.1
/usr/bin/git push origin --tags
To https://github.com/DimensionDev/aot-secure-ecmascript
 * [new tag]         @masknet/compartment@0.2.2 -> @masknet/compartment@0.2.2
 * [new tag]         @masknet/static-module-record-swc@0.3.1 -> @masknet/static-module-record-swc@0.3.1
Error: The process '/usr/bin/git' failed with exit code 1
    at m._setResult (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:7258)
    at m.CheckComplete (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:6686)
    at ChildProcess.<anonymous> (/home/runner/work/_actions/changesets/action/v1/dist/index.js:102:5723)
    at ChildProcess.emit (events.js:314:20)
    at maybeClose (internal/child_process.js:1022:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:287:5)
 ! [rejected]        @masknet/intrinsic-snapshot@0.1.0 -> @masknet/intrinsic-snapshot@0.1.0 (already exists)
error: failed to push some refs to 'https://github.com/DimensionDev/aot-secure-ecmascript'
hint: Updates were rejected because the tag already exists in the remote.
Error: The process '/usr/bin/git' failed with exit code 1

it should not try to tag and push existing package tags.

[Jack-Works]

I find out a workaround. When checkout the repo on CI, you should check out all commits and tags so that the changeset can skip the duplicated tags.

[Andarist]

A better solution for this would be to only fetch the list of tags, perhaps using some fetch command with --depth 1. This would spare you fetching the whole repo.

Ideally, I think that we could improve the situation in Changesets as you shouldn't be that concerned about this sort of stuff as the user. We could ask the remote about existing tags before creating them. Part of the question is if it should happen in the changesets/action or if it should happen in the @changesets/cli.

[DanieliusDev]

A better solution for this would be to only fetch the list of tags, perhaps using some fetch command with --depth 1. This would spare you fetching the whole repo.

Ideally, I think that we could improve the situation in Changesets as you shouldn't be that concerned about this sort of stuff as the user. We could ask the remote about existing tags before creating them. Part of the question is if it should happen in the changesets/action or if it should happen in the @changesets/cli.

it seems like actions/checkout fetch-depth defaults to 1? should i switch to 0?

[Andarist]

That is a feasible workaround for this issue. It's just that your action will be a little slower with that as you will start fetching the whole history of the repository (instead of just the latest commit).

[DanieliusDev]

That is a feasible workaround for this issue. It's just that your action will be a little slower with that as you will start fetching the whole history of the repository (instead of just the latest commit).

well apparently fetch-depth 1 doesnt work bc its a default for actions/checkout

[Jack-Works]

the default depth 1 doesn't include the old release tags. I suspect that any random number will not work, for example, you set it to fetch-depth: N and you push N+1 commits without a new release...

[DanieliusDev]

the default depth 1 doesn't include the old release tags. I suspect that any random number will not work, for example, you set it to fetch-depth: N and you push N+1 commits without a new release...

So i should stick with 0 depth then?

[Andarist]

For the time being - yes. It would be great to fix this in the Changesets itself eventually though.

[DanieliusDev]

For the time being - yes. It would be great to fix this in the Changesets itself eventually though.

Alr, ty :)

[Jack-Works]

see actions/checkout#947

[Andarist]

@Jack-Works you mentioned in the linked issue that:

this can improve #201 which requires tag & commit history but does not need files of it

but as far as I understand the things mentioned in the git documentation, --shallow-since would still fetch the files. And also - what kind of an argument you would even give to it to solve the problem here? 🤔 Am I missing something?

[Jack-Works]

Looks like the changeset must have access to the git history to work correctly, this (shallow) is the cheaper way than clone-depth: 0

[Andarist]

Right, that's definitely true - but you can already create shallow clones today. I see though how perhaps specifying a computed date is less error-prone than specifying a depth, I just wasn't sure if you were referring to that.

I still think though that we can probably just fetch the list of the tags from the remote (or swallow errors from "retagging" attempts). So it could be fixed in Changesets - just nobody got to implementing it yet.

[przlada]

Hi 👋 what do you think about running git fetch --tags origin after the checkout step as a workaround? AFAIK it will also fetch files, but it is some kind of improvement from fetch-depth: 0. It looks to be working for me.

steps:
  - name: Checkout Repo
    uses: actions/checkout@v3
  - name: Git fetch tags 
    run: git fetch --tags origin

[tsteckenborn]

Was this resolved or does somebody have a proper workaround?

If I got it correctly, right now if there's no changeset it tries to create tag again, even if it's already there. I'm just not sure on my expected behaviour. Should it skip publish in this case or publish but ignore the tag (potentially yielding to deployments in case deployments react to publish / unclear if there are no changesets because of release or due to e.g. a simple change in a readme that shouldn't necessarily trigger a release / version).