[FIXED JENKINS-14862] add option to get the whole repository on clone/pull

[domruf]

if you want to build a tag it is necessary to pull the whole repository
JENKINS-14862

[buildhive]

Jenkins » mercurial-plugin #132 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

Jenkins » mercurial-plugin #133 FAILURE
Looks like there's a problem with this pull request
(what's this?)

[buildhive]

Jenkins » mercurial-plugin #134 ABORTED

(what's this?)

[jglick]

Adding this flag to MercurialInstallation makes no sense. It would need to be on MercurialSCM. (MercurialSCMSource can I think unconditionally pass false, since this feature only makes sense with branches.)

And a pull request should include a new test that fails (in all the expected ways) without the change and passes with it. In this case I would expect to see a test method in SCMTestBase (so that it is checked both with and without caching enabled) which for example creates a repo with a tagged changeset, sets up a job based on that tag, does an initial build including clone, moves the tag, and does a second build which verifies that the workspace now is updated to the new changeset, and the changelog gives the difference between the old and new changesets. Would also make sense to test the scenario of a parameterized build where the build parameter is substituted into a tag name.

[jglick]

As mentioned in #20, when caching is on, probably the clone into the workspace can unconditionally omit --rev: the cache will already be a complete clone, and the repository in the workspace should be hardlinked to it so there should be little additional disk consumption. But when caching is off, then --rev should be used when possible to minimize disk space.

[jglick]

From a UI perspective adding an option to “clone the whole repository” is also probably the wrong approach; it forces the user to think about the plugin’s implementation. What the user really needs to say is that the Branch field is actually referring to a tag. So probably what the UI should have is a dropdown next to this field that lets the user say what they are entering:

• branch (the default)
• bookmark
• tag
• explicit changeset

Then it is up to the plugin to adjust its behavior according to the kind of update target. Currently that might mean nothing more than omitting --rev when doing an uncached clone/pull and the target is a tag; but there might be other behavioral tweaks we would want to make in the future, such as showing the changelog differently depending on the mode.

[patoarvizu]

I may have done it wrong, or have an older version of the plugin, but I thought that when caching was on, it just meant that Jenkins had a local copy of the repository in a general workspace area and then jobs cloned from THAT repository, so it wasn't hard-linked.

I was assuming that the point of this was to minimize time to clone (because the repository the jobs were cloning from was local) rather than optimizing for disk space.

In any case, I like this feature, thanks for implementing it :).

[jglick]

When caching is enabled, Jenkins will keep a full clone of the remote repository on the master. Then, if the job is built on a slave, it will keep a full clone of that on the slave (implemented by bundling and transferring changesets from the master over the remoting channel: the slave need have no public network connection). Finally, the job’s workspace will have a clone of the local cache, and that should be hardlinked since it is on the same disk.

The main point of caching is to minimize traffic to the public repository. The disk consumption is larger.

[patoarvizu]

Got it, thanks for clarifying.

[domruf]

You are right from a UI perspective it is not ideal, but neither is an additional drop down box I thinnk.
The reason I did it this way is that the additional complexity here is not in the project configuration but only in the global configuration. So users is not confronted with it that often.
The ideal solution I think would be to detect if we are dealing with a tag or not and acting accordingly.
But I have not found a way to detect remotely if a sting is a tag/branch/bookmark (yet).

[jglick]

I do not think you can detect whether something is a tag in advance. You would have to actually pull everything and search for that label.

Putting this flag in the global configuration is just incorrect: some projects may be using tags and others branches. This has nothing to do with which Mercurial installation you use.

Closing since this is a relatively major change and I probably need to do this work myself.