Repository navigation
Always try to push invalid tags聽#201
Description
Activity
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.
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/actionor if it should happen in the@changesets/cli.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/actionor if it should happen in the@changesets/cli.it seems like
actions/checkoutfetch-depthdefaults to1? should i switch to0?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).
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-depth1 doesnt work bc its a default foractions/checkoutthe default depth
1doesn't include the old release tags. I suspect that any random number will not work, for example, you set it tofetch-depth: Nand you push N+1 commits without a new release...the default depth
1doesn't include the old release tags. I suspect that any random number will not work, for example, you set it tofetch-depth: Nand you push N+1 commits without a new release...So i should stick with 0 depth then?
For the time being - yes. It would be great to fix this in the Changesets itself eventually though.
For the time being - yes. It would be great to fix this in the Changesets itself eventually though.
Alr, ty :)
@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-sincewould 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?Looks like the changeset must have access to the git history to work correctly, this (shallow) is the cheaper way than clone-depth: 0
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.
Hi 馃憢 what do you think about running
git fetch --tags originafter the checkout step as a workaround? AFAIK it will also fetch files, but it is some kind of improvement fromfetch-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
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).
it should not try to tag and push existing package tags.