Git Plugin Checkout From Branch With Tag

[eric....@gmail.com]

OK, I think I've tried everything in this OLD conversation, but none of them work.  I have no issues checking out from a branch using branch specifier.  I've tried adding on to the specifier:  ${my_branch} tags/${my_tag}.  Have also added another branch and used this sort of thing (as well as every other way they said to do it in that thread).  Every way seems to just get the tip revision of all the files in that branch.  Does anyone have guidance of how to get this done?  Thanks!  Eric

[Eric Fetzer]

Tried a bunch more stuff using Git Parameters:

https://plugins.jenkins.io/git-parameter/

Again, I can checkout from the branch, but not using the tag.  I set a git parameter for branch and then put it in the branch specifier and that worked.  I added another for tag, then put that in the same branch specifier after a space and got an error.  If I put it in an additional branch specifier, it seems to have gotten ignored.  Just got the tip revision from that branch.

On Tue, Apr 13, 2021 at 12:57 PM eric....@gmail.com <eric....@gmail.com> wrote:

OK, I think I've tried everything in this OLD conversation, but none of them work.  I have no issues checking out from a branch using branch specifier.  I've tried adding on to the specifier:  ${my_branch} tags/${my_tag}.  Have also added another branch and used this sort of thing (as well as every other way they said to do it in that thread).  Every way seems to just get the tip revision of all the files in that branch.  Does anyone have guidance of how to get this done?  Thanks!  Eric

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/UGyBIx3pX9s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c045a834-8d68-46fe-8b72-860e89416209n%40googlegroups.com.

[Mark Waite]

As far as I can tell, you didn't provide the context of the old conversation.  The steps you've attempted and the context where you're trying those steps are not clear to me.  The comments that follow are my guesses of things that might help you.

If you're using Jenkins Pipeline and want to checkout a tag in your parameterized job, you must use the 'checkout scm' step rather than the 'git' step.  The Pipeline snippet generator will help you generate the correct syntax for your desired checkout.  There is a brief video included in the git plugin documentation that shows how to use the Pipeline snippet generator.  The git step documentation warns that 'checkout' is the preferred step and that tag checkout is not supported with the git step.

If you're using a Freestyle job, then you may need to check that you're fetching the tags and that the tag parameter you're providing is being placed in the "Branch to build" as a variable to be expanded.

Mark Waite

[eric.fetzer]

I am SO sorry Mark, I confused this Jenkins thread with a totally unrelated support ticket.  I'm not using pipeline, just the git plug in in conjuction with git parameters.  What exactly do you mean by fetching the tags?

Sent from my T-Mobile 4G LTE Device

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/54da0d5e-e11e-4564-a7b4-c2a49f94efaan%40googlegroups.com.

[Mark Waite]

On Tue, Apr 13, 2021 at 5:57 PM eric.fetzer <eric....@gmail.com> wrote:

I am SO sorry Mark, I confused this Jenkins thread with a totally unrelated support ticket.  I'm not using pipeline, just the git plug in in conjuction with git parameters.  What exactly do you mean by fetching the tags?

I defined a Jenkins Freestyle job that fetches a specific tag and verifies within the job that the specific tag was fetched.  You can read the job definition if that helps.

Crucial portions of the job definition included:

Define the parameter for the tag to checkout

Use the parameter in the checkout as the local branch name

I believe the default behavior is to fetch tags, but I included it in the job definition as part of "Advanced clone behaviors" to be certain.

I enabled "Honor refspec on initial clone" because that test repository is very large and I only wanted a specific branch in the clone.  You  probably won't need that option, though it does no harm to enable it.

Mark Waite

 

You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/60762fe0.1c69fb81.51b85.e697%40mx.google.com.

[Eric Fetzer]

Thanks for the detailed description Mark!  Only one thing confuses me, I don't see you specifying the branch to build anywhere in there.  Can you explain that to me because I have to specify the branch as well as the tag?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGWDMtyBiP%3D3BtFPcr%3Drz7E6wxpEu3gcg2MXZZMFwmUpA%40mail.gmail.com.

[Eric Fetzer]

So I've tried to incorporate what you've said, Mark, but it still just clones the tip revision (9.9.9.10 in this case).  Here are my tags:

git show-ref --tags -d
4efbdb878c77557d050abbd228fc377adb9419b0 refs/tags/1.0.0.1
799eda70c5f052a6f8e757b044b3b60f704a705a refs/tags/1.0.0.1^{}
c516e3681d2675d4e407b3c26ddfc7da0404c898 refs/tags/1.0.0.2
40bf9dd858780d79facfb789921f53d673c08dc9 refs/tags/1.0.0.2^{}
9083515085949bfad75f028194226f5a9b1e5ecf refs/tags/9.9.9.10
49b0f2cfbf93f36acf6b2124d589a64940eecf18 refs/tags/9.9.9.10^{}
019b3f3c634b9071c43f570a62c1191be05c0f4e refs/tags/9.9.9.9
b2f49473794ad74af0e5943f9292e57e05938fbe refs/tags/9.9.9.9^{}

I'm trying to get 9.9.9.9.  Here is my setup:

It is honoring the branch specifier for branch, but not for tag.  I've tried it with just ${tag_name} as well as with tags/${tag_name} as well as refs/tags/${tag_name}.  What am i doing wrong?  Thanks!!!

[Mark Waite]

Don't use a branch parameter.  Place the tag name in the "Branches to build" field.  Compare my screen shots and your screen shots.  You have more things in your job definition than I have in mine.  Those extra things are causing the behavior you're seeing

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicbGY6zUALbS2ApvuFVv2Aa1ggUxfE5kQF2vYguHeCEPSQ%40mail.gmail.com.

[Eric Fetzer]

Well if I don't tell it what branch to get, how will it get the right branch?  Sorry, Github is a paradigm shift for me.  I've been using StarTeam for 20 years and github for just a few weeks now...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtESHA%2BspxLHvufnWx_sPyOXHQszn7TMgubsjw8SL1p0cA%40mail.gmail.com.

[Mark Waite]

On Wed, Apr 14, 2021 at 10:22 AM Eric Fetzer <eric....@gmail.com> wrote:

Well if I don't tell it what branch to get, how will it get the right branch?  Sorry, Github is a paradigm shift for me.  I've been using StarTeam for 20 years and github for just a few weeks now...

No problem.  Been through that paradigm shift.  Took a long time before the key git concepts finally registered.

A git tag represents a specific commit.  A checkout of a tag does not need a branch.  In your case, you're asking for a branch and a tag.  The git plugin decided to give you the branch instead of the tag.  If you only ask for a tag, it will checkout the commit at that tag.

Mark Waite

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicZNnvSTE5yMsPLzRW92QYtA2VFJBCpGzuLWmES58FMpZw%40mail.gmail.com.

[eric.fetzer]

Thamks Mark!  So how would I go about checking out a branch based on a point in time (a label in most systems)?  Is there a way to snap a label and then check out based on that label or are we resigned to only deal in tip revisions?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGSgw8%2BB3CYSB_sYk2qBegE0mVhpDW%2BEStFpf_2XxT5JA%40mail.gmail.com.

[Mark Waite]

On Wed, Apr 14, 2021 at 12:16 PM eric.fetzer <eric....@gmail.com> wrote:

Thamks Mark!  So how would I go about checking out a branch based on a point in time (a label in most systems)?  Is there a way to snap a label and then check out based on that label or are we resigned to only deal in tip revisions?

You can checkout a point in time by checking out a specific SHA-1 hash that is the most recent commit before that point in time.  See https://stackoverflow.com/questions/6990484/how-to-checkout-in-git-by-date .

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/60773155.1c69fb81.6a883.10c8%40mx.google.com.

[Eric Fetzer]

So when you turn a tag into a release, does it then act more like a label, or is it still just a set of changed files?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGqzU-Q%3Dx4wrkgKWjP6fi%3DDX8uRQcYPqtLEB4%3DNrWRxdA%40mail.gmail.com.

[Eric Fetzer]

So here's what blows my mind about a tag.  If I go to the tag in GitHub Enterprise, it has a .zip and .tar.gz associated with it.  If I unpack that file, it has the entire contents of the repository in it.  That seems like a view label to me.  But yet all of the documentation talks about the tag as a change set.  I don't get it!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGqzU-Q%3Dx4wrkgKWjP6fi%3DDX8uRQcYPqtLEB4%3DNrWRxdA%40mail.gmail.com.

[Mark Waite]

On Thu, Apr 15, 2021 at 7:38 AM Eric Fetzer <eric....@gmail.com> wrote:

So when you turn a tag into a release, does it then act more like a label, or is it still just a set of changed files?

Refer to https://git-scm.com/book/en/v2/Git-Basics-Tagging for more details on the meaning and use of git tags.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicbDVmXwAAE1YVY-gXyf9SyF8dLQWAYB-YpEv5b3tggEXA%40mail.gmail.com.

[Eric Fetzer]

Thanks Mark!  I'll quit whining and displaying my total git inadequacy, lol...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtGP1VC%3DfVJd9fJFSfbK3fcJmjhVNz-K4K7-rTg2dwjo6w%40mail.gmail.com.

[Mark Waite]

Not taken as whining, just that any attempt I made to explain would be riddled with inadequacies and misuse of terminology.  The definitive documentation has more reviewers and more people that try to assure it is correct, complete, and consistent.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAByBicaRzcx2aaMg3-TWHZ21okhpU6NEed1-Ou-j%2BoXXpvwGzQ%40mail.gmail.com.

[Eric Fetzer]

Thanks Mark!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtER01XhOOB3XSaUwDv1W%2BBo5whJcfMG1Ki15j%3DJp0jR1A%40mail.gmail.com.

[Dirk Heinrichs]

Am Donnerstag, den 15.04.2021, 08:47 -0600 schrieb Eric Fetzer:

So here's what blows my mind about a tag.  If I go to the tag in GitHub Enterprise, it has a .zip and .tar.gz associated with it.  If I unpack that file, it has the entire contents of the repository in it.  That seems like a view label to me.  But yet all of the documentation talks about the tag as a change set.  I don't get it!

GitHub, GitLab, <place name here>, and all those sites are NOT Git. They are collaboration platforms that use Git for source code management and offer some additional tooling around it. One such offer is to allow the user to download a ZIP or Tar archive of a particular state of a repository (i.o.w.: a snapshot, w/o the history), which can be identified by a Git tag, but also by a changeset identifier (for example: https://github.com/saltstack/salt/archive/d240e450f449f16ef176a9cb563b9f0447687a6e.zip). These are usually created on the fly when someone requests the download.

Speaking of Git tags (or branches): They're all the same, a reference to a specific changeset. The only difference is that branch refs are a moving target (they always reference the latest changeset of a particular branch of development), while tags are not.

HTH...

Dirk

-- 

Dirk Heinrichs

Senior Systems Engineer, Delivery Pipeline

OpenText ™ Discovery | Recommind

Phone: +49 2226 15966 18

Email: dhei...@opentext.com

Website: www.recommind.de

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan, Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.

[Eric Fetzer]

That's excellent news Dirk!  That means the process I want to follow will work perfectly.  Since I tag as I checkout from a branch, my tag will apply to that entire branch at that point in time.  That way, when I later check out by tag, I will have that branch at that point in time.  In the past, we've used the same labels on different branches, though.  But since github tags aren't a respecter of branches, I'll have to just use a different naming schema in dev branches vs. the prod branch.  So for dev, I might have 1.0.0.1.1, 1.0.0.1.2, 1.0.0.1.3, and then when that gets merged to the master, I'd build 1.0.0.1.  Does this strategy make sense?  Thanks!  Eric

--

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/UGyBIx3pX9s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/eed9236d95231f0893d0e6a90bc399e28ade9564.camel%40opentext.com.