[JIRA] (JENKINS-40529) Prune tags on fetch

10 views
Skip to first unread message

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 11:08:03 AM12/18/16
to jenkinsc...@googlegroups.com
Y Z created an issue
 
Jenkins / New Feature JENKINS-40529
Prune tags on fetch
Issue Type: New Feature New Feature
Assignee: Mark Waite
Components: git-plugin
Created: 2016/Dec/18 4:07 PM
Priority: Major Major
Reporter: Y Z

The git-plugin doesn't prune tags on fetch and it comes to the situation when there are a lot of unused tags already fetched and stored locally in .git even though that tags in central repository were already removed.

In cases when the build process is based on tags, old tags could play a role and break the custom build logic.

To avoid this, there is an option to delete a workspace entirely before build, however it doesn't look like a right and nice solution to clone everything again.

It would help a lot if there will be an option implemented to prune tags on fetch such as

  1. git fetch --prune origin +refs/tags/:refs/tags/
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 11:10:02 AM12/18/16
to jenkinsc...@googlegroups.com
Yuriy Zaplavnov updated an issue
Change By: Yuriy Zaplavnov
The git-plugin doesn't prune tags on fetch and it comes to the situation when there are a lot of unused tags already fetched and stored locally in .git even though that tags in central repository were already removed.

In cases when the build process is based on tags, old tags could play a role and break the custom build logic.

To avoid this, there is an option to delete a workspace entirely before build, however it doesn't look like a right and nice solution to clone everything again.

It would help a lot if there will be an option implemented to prune tags on fetch such as
# $ git fetch --prune origin +refs/tags/*:refs/tags/*

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 11:10:02 AM12/18/16
to jenkinsc...@googlegroups.com
Yuriy Zaplavnov updated an issue
The git-plugin doesn't prune tags on fetch and it comes to the situation when there are a lot of unused tags already fetched and stored locally in .git even though that tags in central repository were already removed.

In cases when the build process is based on tags, old tags could play a role and break the custom build logic.

To avoid this, there is an option to delete a workspace entirely before build, however it doesn't look like a right and nice solution to clone everything again.

It would help a lot if there will be an option implemented to prune tags on fetch such as
# git fetch --prune origin +refs/tags/*:refs/tags/*

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 11:11:01 AM12/18/16
to jenkinsc...@googlegroups.com
Yuriy Zaplavnov updated an issue
The git-plugin doesn't prune tags on fetch and it comes to the situation when there are a lot of unused tags already fetched and stored locally in .git even though that tags in central repository were already removed.

In cases when the build process is based on tags, old tags could play a role and break the custom build logic.

To avoid this, there is an option to delete a workspace entirely before build, however it doesn't look like a right and nice solution to clone everything again.

It would help a lot if there will be an option implemented to prune tags on fetch such as

{code: shell none }

# git fetch --prune origin +refs/tags/*:refs/tags/*
{code}

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 11:11:01 AM12/18/16
to jenkinsc...@googlegroups.com
Yuriy Zaplavnov updated an issue
The git-plugin doesn't prune tags on fetch and it comes to the situation when there are a lot of unused tags already fetched and stored locally in .git even though that tags in central repository were already removed.

In cases when the build process is based on tags, old tags could play a role and break the custom build logic.

To avoid this, there is an option to delete a workspace entirely before build, however it doesn't look like a right and nice solution to clone everything again.

It would help a lot if there will be an option implemented to prune tags on fetch such as
$
{code:shell}
# git fetch --prune origin +refs/tags/*:refs/tags/*
{code}

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 18, 2016, 12:01:02 PM12/18/16
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 18, 2016, 12:05:02 PM12/18/16
to jenkinsc...@googlegroups.com
Mark Waite commented on New Feature JENKINS-40529
 
Re: Prune tags on fetch

Could you further explain the benefits you see from pruning tags? Does it reduce objects fetched, does it reduce local disc space, or is it something completely different?

The option to not fetch tags (for those jobs which don't need tags) is already a part of the advanced clone options so that additional references are not brought in through cloning the tags. The option to prune the repository of remote branches which have been deleted is already a part of the advanced clone options, for those who want to remove remotely deleted branches from their local repository. The option to request one or more custom refspecs is already part of the git repository definition portion of the job (thus, you could ask to only clone tags), and the ability to honor a custom refspec on initial clone is already part of the advanced clone options.

yura.zaplavnov@gmail.com (JIRA)

unread,
Dec 18, 2016, 6:26:01 PM12/18/16
to jenkinsc...@googlegroups.com
Yuriy Zaplavnov edited a comment on New Feature JENKINS-40529
Yes, the options such as to prune the branches or to fetch the specific refspec are available and they are the part of the advanced options, however they are unfortunately not relevant to the case I'm looking for. Let's imagine there is a job which is configured to clone repository and pull the changes for the specific branch. Additionally to the changes, all the tags associated with commits within that branch are also retrieved from central repository. For example: Step 1: there is a branch 'test-branch' which is supposed to be retrieved and pulled for the changes. The 'test-branch' contains the commits with associated tags: 'test-tag1', 'test-tag2'. Step 2: Run job, and all those tags will be fetched from origin. Step 3: Someone updates origin by removing tag 'test-tag2' and associating a new tag 'test-tag3' with a commit within our sample branch 'test-branch'. Step 4: Run job, and our workspace would contain new tag 'test-tag3', and old one 'test-tag2' which was removed in origin (but still exists in checked workspace). The goal is to do not have 'test-tag2' in checked workspace, because it doesn't exist already in origin. As far as I see there is no way at the moment how it could be achieved by using the git-plugin, therefore I wondered to prune tags.

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 18, 2016, 6:50:01 PM12/18/16
to jenkinsc...@googlegroups.com

Thanks for the additional details. Thanks makes it much clearer for me.

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 9, 2017, 9:19:01 PM2/9/17
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on New Feature JENKINS-40529
Thanks for the additional details.   Thanks   That makes it much clearer for me.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 7:58:04 AM3/27/19
to jenkinsc...@googlegroups.com

If it was possible to have multiple ref specs in the 'specify ref specs' behavior, this would actually be possible by adding the ref spec +refs/tags/:refs/tags/ }}(this even works with {{--no-tags).

Unfortunately this doesn't seem to be supported by git-plugin:

ERROR: [on mar. 27 12:48:52 GMT+01:00 2019] Could not fetch branches from source 6728e3b7-48a3-458c-9153-0da05369031f
java.lang.IllegalArgumentException: Invalid refspec refs/heads/*:refs/remotes/origin/* +refs/tags/*
	at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:539)
	at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:191)
...

This validation error happens when the specified ref spec is '+refs/heads/:refs/remotes/@{remote}/ +refs/tags/:refs/tags/'

 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 7:59:03 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
If it was possible to have multiple ref specs in the 'specify ref specs' behavior, this would actually be possible by adding the ref spec ' {{+refs/tags/ * :refs/tags/* }} '* (this even works with {{--no-tags}}).


Unfortunately this doesn't seem to be supported by git-plugin:
{code:java}

ERROR: [on mar. 27 12:48:52 GMT+01:00 2019] Could not fetch branches from source 6728e3b7-48a3-458c-9153-0da05369031f
java.lang.IllegalArgumentException: Invalid refspec refs/heads/*:refs/remotes/origin/* +refs/tags/*
at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:539)
at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:191)
... {code}
This validation error happens when the specified ref spec is '+refs/heads/*:refs/remotes/@\{remote}/* +refs/tags/*:refs/tags/*'

 

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 7:59:03 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
If it was possible to have multiple ref specs in the 'specify ref specs' behavior, this would actually be possible by adding the ref spec '{{+refs/tags/:refs/tags/*'*(this even works with {{ --no-tags}}).


Unfortunately this doesn't seem to be supported by git-plugin:
{code:java}
ERROR: [on mar. 27 12:48:52 GMT+01:00 2019] Could not fetch branches from source 6728e3b7-48a3-458c-9153-0da05369031f
java.lang.IllegalArgumentException: Invalid refspec refs/heads/*:refs/remotes/origin/* +refs/tags/*
at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:539)
at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:191)
... {code}
This validation error happens when the specified ref spec is '+refs/heads/*:refs/remotes/@\{remote}/* +refs/tags/*:refs/tags/*'

 

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:06:03 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
If it was possible to have multiple ref specs in the 'specify ref specs' behavior, this would This is actually be possible by adding the ref spec '{{+refs/tags/ * :refs/tags/* ' * (this even works with --no-tags}}).

Unfortunately this doesn ' t seem to be supported by git-plugin:

{code:java}
ERROR: [on mar. 27 12:48:52 GMT+01:00 2019] Could not fetch branches from source 6728e3b7-48a3-458c-9153-0da05369031f
java.lang.IllegalArgumentException: Invalid refspec refs/heads/ * :refs/remotes/origin/* +refs/tags/*

at org.eclipse.jgit.transport.RefSpec.checkValid(RefSpec.java:539)
at org.eclipse.jgit.transport.RefSpec.<init>(RefSpec.java:191)
... {code
}
This validation error happens when } using the specified 'specify ref spec is specs ' +refs/heads/*:refs/remotes/@\{ behavior - stale local tags will be deleted, and new remote }/* +refs/ tags /*:refs/tags/*'

  will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:07:04 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
This is actually possible by adding the ref spec '{{+refs/tags/*:refs/tags/**'*}} using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:07:04 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
This is actually possible by adding the ref spec '{{+refs/tags/* * :refs/tags/** * '*}} using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:08:01 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
This is actually possible by adding the ref spec ' {{+refs/tags/* * :refs/tags/* **'* }} using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:09:04 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
This is actually possible by adding the ref spec {{ +refs/tags/*:refs/tags/* }} using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:09:05 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
This is actually possible by adding the ref spec ' +refs/tags/ \ *:refs/tags/ \ * ' using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:23:03 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
[~xeagle]

This is actually possible by adding the ref spec '+refs/tags/ \ *:refs/tags/ \ *' using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched.

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:47:04 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
[~xeagle]

This is actually possible by adding the ref spec '+refs/tags/*:refs/tags/*' using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched. Fetch must also have '--prune' specified, but you probably already use that (--prune can be added by using the 'Prune stale remote-tracking branches' behavior, or 'git config fetch.prune true').

bruder@bruder.dk (JIRA)

unread,
Mar 27, 2019, 8:47:05 AM3/27/19
to jenkinsc...@googlegroups.com
Jesper Matthiesen edited a comment on New Feature JENKINS-40529
[~xeagle]

This is actually possible by adding the ref spec '+refs/tags/*:refs/tags/*' using the 'specify ref specs' behavior - stale local tags will be deleted, and new remote tags will be fetched. Fetch must also have ' \ - \ -prune' specified, but you probably already use that ( \ - \ -prune can be added by using the 'Prune stale remote-tracking branches' behavior, or 'git config fetch.prune true').

nfalco79@hotmail.com (JIRA)

unread,
Feb 28, 2020, 9:07:02 AM2/28/20
to jenkinsc...@googlegroups.com

This feature is really wanted for us. Every time a maven release:prepare release:perform fails it create a local tag and if we run the build again it fails due to that. We need to login in SSH on the jenkins slave node and remove them manually.
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
Atlassian logo

nfalco79@hotmail.com (JIRA)

unread,
Feb 28, 2020, 2:24:03 PM2/28/20
to jenkinsc...@googlegroups.com
Nikolas Falco assigned an issue to Nikolas Falco
Change By: Nikolas Falco
Assignee: Nikolas Falco

nfalco79@hotmail.com (JIRA)

unread,
Apr 10, 2020, 12:40:05 PM4/10/20
to jenkinsc...@googlegroups.com
Change By: Nikolas Falco
Status: Open Fixed but Unreleased
Resolution: Fixed
Reply all
Reply to author
Forward
0 new messages