Use `--tags` option when fetching repo updates

The default is to fetch updates from a repo instead of cloning the complete repo again, which is great.

The drawback is that then tags are usually not available and using things like git describe in build/packaging/deploy steps won't correctly work any more.

So I propose to add the --tags option to the git fetch command (writeFetchCmd in shells/bash.go, etc.) so that tag objects (annotated tags) are also fetched. See https://git-scm.com/docs/git-fetch

That should make git describe (and anything else that need the tags) work with the faster (and default) fetch option.

It would also be nice to have an options which automatically tags the repo. This could be conditional on the build passing. For example, if the build passed there could be a tag added like: CIBUILD-

$CI_BUILD_REF_NAME-$

CI_PROJECT_ID.CI_BUILD_ID

Then the commit will never be garbage collected if it is ever rebased and made into a dangling commit and it is easy to reference from scripts.

Thanks. I'll add the --tags in upcoming 1.1 release.

Milestone changed to v1.1

Added improvement label

Great. Thanks @ayufan!

To be safe, it would probably be a good idea to prune refs/tags as well... So that if a tag is deleted in the repo, it will be properly reflected in the ci runner repo.

Unfortunately simply adding --prune additionally will not prune already existing tags: http://git-scm.com/docs/git-fetch So it seems it would be necessary to do something like: git fetch origin --prune "+refs/tags/*:refs/tags/*" explicitly after a normal fetch...

@flixr To make my live easier maybe you could provide a set of commands that we should execute? :)

Then it may land in on of the upcoming patch releases to make your happy :)

@ayufan sure :-)

Unfortunately I haven't found a way to specify this with only one git fetch.

But in my tests here doing a git fetch origin --prune "+refs/tags/*:refs/tags/* after the current normal git fetch seems to do the job.

Meaning it seems to fetch all new tags, remove tags that were deleted in the main repo and "recreate" tags that were "moved" (deleted and a new one created with same name but on different commit).

To me that seems to be the most reliable way (instead of only adding --tags to the current fetch command).

@flixr Would you be so kind to prepare MR? :)

@ayufan Um... I haven't done anything in go so far (and only tested this via git commandline), but I'll try to find some time to give this a shot tomorrow.

@flixr We can do Hangout and I can show you around to make it easier for you :)

I would need reasoning why we choose this git command. The problem is also that currently executed git commands are compatible with Git down to 1.6 :)

Unfortunately I haven't found a way to specify this with only one git fetch.

Is there any reason it must be in one invocation of git? Travis, for example, does multiple invocations of git when building PRs from GitHub (example) (one for the initial shallow clone, and another for the hidden refs/pull/35/merge ref that GitHub uses for PR merge tests).

Also, could the runner bundle a Go implementation of Git itself, instead of needing to execute an external git command? This would avoid any git version dependencies.

@jonathon-reinhart The git fetch is time consuming. All other that doesn't talk to server can be split.

@jonathon-reinhart of course it doesn't have to be done in one git invocation. But would have been nice...

So I indeed propose to invoke git twice, once with the "normal" fetch as before and a second time with the command posted earlier.

Ok, it's possible to do it in one git invocation since you can actually specify multiple refspecs. See MR !78 (merged)

@ayufan see MR !78 (merged)

Status changed to closed