Can't push without tags

[njbennett]

A put command to a github resource is always a git push --tag. We use tags to mark release versions and commits deployed to specific environments. Right now, we have to delete all tags locally in our scripts before pushing from Concourse. We would prefer to be able to just specify in our plan configuration that we don't want to push tags, or for this to be the default behavior.

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #112642521 Can't push without tags

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[vito]

What's fetching with tags or creating them? We also use tags and don't experience this behavior. Agreed that it should be something you can turn off, but I'm not sure about by default; the idea is that if there are tags there it's because your script created them, so you probably want them pushed.

[njbennett]

As far as I can tell, the issue is that we (Billing & Accounts Management) share our repo with another team (Apps Manager). They use tags to mark commits deployed to various CI environments and to mark commits released in various versions of PCF; they delete the tags that associate commits with CI environments in their GoCD scripts and recreate them when they push new commits to those environments.

We've always just ignored these tags, because we were pushing with GoCD scripts rather than through Concourse. Concourse is basically making us more aware of the weird thing our sister team is doing with tags, and forcing us to mirror that behavior in our CI. So this might just be something that can be chalked up to "doing something weird with Github tags + odd team/repo structure."

[vito]

Gotcha. I'm just confused as to how the tags are being introduced to the local repo in the first place. When the repo is fetched, we don't fetch the tags; any tags being pushed must have been created in your script, which Concourse takes to mean that you want them pushed. Or I may be wrong, and it is fetching the tags, and normally pushing does a no-op, but if the tags have since changed remotely it'll try to clobber them?

Can you confirm that your job isn't creating any tags? I'm not totally against adding this param, I just want to make sure it's for the "right reason".

[njbennett]

We're pretty sure that we're not making tags. The only times "tag" appears in our ci repo are to delete them, and in reference to our Ubuntu image.

How are you fetching without tags? It looks like git fetch, clone, and pull all bring in all the tags on the branches involved by default, and maybe even that tags can't, or shouldn't, not be pulled down.

[vito]

Yep looks like a fresh clone does bring in the tags. I must have been thinking of something else. In that case it's probably that after cloning, the tag has changed remotely, and the git push --tags ends up trying to roll it back.

I would rather have the tags not be present after fetching. They're not really meant to be there, especially as the caching semantics get a little weird (it'll have cached tags that were present only when the cache is warmed).

[xoebus]

Having tags change the commit that they're pointing at is a little scary and a misuse of tags. If you want a named pointer that can move to different commits then branches are the way to go. I'm going to close this as a WONTFIX but I'd probably accept a PR that caused us to not fetch tags when we clone a repository.

[njbennett]

That's reasonable. The optimal thing for us would be to not interact with their tags at all.