-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always try to push invalid tags #201
Comments
A better solution for this would be to only fetch the list of tags, perhaps using some fetch command with 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 |
it seems like |
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 |
the default depth |
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. |
Alr, ty :) |
@Jack-Works you mentioned in the linked issue that:
but as far as I understand the things mentioned in the git documentation, |
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 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.
The text was updated successfully, but these errors were encountered: