Git plugin - feature branch frustrations

[Nigel Magnay]

So I'm trying to set up the git plugin to build feature branches.

Features are on branches like feature/foo and feature/blah. This is a common pattern as it's derived from git-flow.

I seem to have tried every combination of branch specifiers, and all this results in is jenkins building the same SHA1 over, and over again. I've tried removing wildcards, and specifying directly two branch specifiers in multiple different formats (refs/heads/features/A, remotes/origin/features/A) all to no avail.

All of them seem to result in a polling log declaring nonexisting_workspace which I don't understand since determining if there are changes ought not to require a checkout. But it simply re-triggers and fills up my disks.

What have I missed?

[Mark Waite]

I've recently been using the multi-branch plugin with great success.  It automatically creates a new job for each branch it detects, rather than "hiding" the detection of a new branch inside the execution history of a single job.  You might experiment with it to see if it meets your needs better than building different branches in the same job.

I believe the "nonexisting workspace" message is evidence of a bug in the plugin.  I don't know the depth or breadth of the bug, but I've seen the same message.  If you find a clean way to duplicate it, please submit a bug report to track it.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TA_0H5vhRRh-YxNLjrFqJGnMXtZjHkn5bA83sPzzHyWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Nigel Magnay]

Multi-branch looks useful, but sadly this project uses the maven project type.

I did see some reports about it getting confused that the branch name has a '/' in it. If I get a chance I'll try and diagnose.

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

[Mark Waite]

Considering how poorly a number of developers think of the maven project type, aren't you at least tempted to try a multi-branch with a maven build step, rather than using the maven project type?  I think your users will thank you.

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83T%2B8bv6DKueX1%2BGULP9As4sj%3Drgxgiz5mkmxvpCiRgQ%2BA%40mail.gmail.com.

[Nigel Magnay]

I don't see why polling via a workspace should be required. 'git ls-remote' is sufficient to determine branch names and SHA1s, and thus to determine if there are any changes to build. And in any case, there will be no workspace, since all builds on lightweight docker containers, torn down immediately after every build.

It's pretty lousy UX that several options seem to imply the need for a workspace (yes, I understand this may be required to do 'advanced' processing, but not in my usecase) - which may never ever exist, resulting in mysterious (because the config page never mentions this) build everything over and again behaviour.

On the project type: that's not that simple, as we rely on the artifact information stored by Jenkins against the build in the maven project type.  But yes, I've never understood why there's a "native/integrated maven build" type - which can invoke maven precisely once- rather than a "native/integrated maven build step". 

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

[Mark Waite]

I agree, it is poor user experience to require a workspace if one is not really needed.

Will you be investigating further and submitting one or more bug reports describing the problems you've found?

Will you be submitting pull requests (with tests) which show the problems and then show that your proposed change has fixed the problem?

Thanks,

Mark Waite

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TRpCmZ6pHOneq85uie7EU%2BmRWSTPyO13NF5OArk2J-6g%40mail.gmail.com.

[nicolas de loof]

ls-remote is indeed sufficient to retrieve branches HEADs, and we got such a change implemented in 2.4.0 development build, BUT git plugin do have some legacy logic to only consider tip branches, i.e. exclude branches that are ancestors for other branches. As a result, we ended with infinite build loop. Mark discovered this just before the release so we had to rollback. 

That being said, multi-branch definitively is a better approach vs the current buggy multi-branch support in git-plugin, and maven job has lot's of side effects and limitations so that some of us consider it the evil job type. Setting equivalent freestyle job require some extra configuration but is feasible afaik.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83TRpCmZ6pHOneq85uie7EU%2BmRWSTPyO13NF5OArk2J-6g%40mail.gmail.com.

[Stephen Connolly]

what multi-branch does with git is to clone the repo to the master that way some of the branch checking can be done without a workspace (i.e. is there a marker file in this branch that would mean we should create a project from the branch)

That does have disk space implications for the master... but it also makes a lot of the polling stuff easier. It would be good if the regular GIT scm polling could share the repo cache and then remove completely the need for a workspace for the "legacy" logic

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzkV-yZLc5q1e7ZCt0JTFHMUBW%3Dhin8MVrz74vKoA5grPw%40mail.gmail.com.