Bump pipeline and git dependencies

[i386]

Description

@michaelneale @vivek a number of new pipeline updates are available we should integrate and test with.

Submitter checklist

• Link to JIRA ticket in description, if appropriate.
• Change is code complete and matches issue description
• Appropriate unit or acceptance tests or explanation to why this change has no tests
• Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.
• Ran Acceptance Test Harness against PR changes.

Reviewer checklist

• Run the changes and verified the change matches the issue description
• Reviewed the code
• Verified that the appropriate tests have been written or valid explanation given

@reviewbybees

[michaelneale]

Still isn't happy with it - probably something else is pulling in 2.10.. perhaps hold off until workflow-api has been fixed?

[michaelneale]

Is there a reason this one is explicitly set?

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[michaelneale]

passes ATH https://ci.blueocean.io/job/ATH-Jenkinsfile/job/master/1718/

[michaelneale]

not sure why some dependencies are added

[michaelneale]

@i386 any reason this is here and not test scoped?

[i386]

Scopes are inherited

[michaelneale]

nice.

[michaelneale]

so - why is this dependency here? It wasn't used before right?

[michaelneale]

well looking good so far according to smoke and ATH tests.

[svanoort]

@i386 We're ready to take this up to 2.12 now

[michaelneale]

@i386 I can't tell what your latest changes are - but they have broken both unit tests and the ATH
Well if I click on the hash above - it shows me a bunch of changes I have already seen before, so I am not sure what is in #9d5d00d

[michaelneale]

why?

[michaelneale]

🐛 some failures and a lot of dependency changes that need a bit more description/work.

[michaelneale]

I don't think we have the luxury of bumping deps all at once unless we have time to baby sit all the tests/ATH. wouldn't it make sense to focus on workflow-api on its own?

[michaelneale]

@i386 did you squash commits here ? as I Can't see changes between today and yesterday to know what caused breakage (best to not squash when pushing to a branch for this reason).

[michaelneale]

🐝 LGTM

[jglick]

Revert 45aa4f0 and fix your tests to checkout scm.

[michaelneale]

@jglick ?? commenting on long closed PRs?

EDIT: I assume you mean that changing tests to not use git but use checkout scm wont' see this problem in 2.13?

[jglick]

commenting on long closed PRs?

Two days! Well within the range of my review backlog, unfortunately…

you mean that changing tests to not use git but use checkout scm

No, IIUC the problem is that there are tests which create a Jenkinsfile which is just, say,

echo 'hi!'

and as of 2.13 (using the now-default lightweight mode—controllable via system property) successive builds of that branch project will not display any SCM changelog, because Jenkins is not running all the machinery of SCM.checkout and its changelog parsing—it is just grabbing the Jenkinsfile straight out of the selected revision (in the case of GitHub, via API). So the test should actually do something with the source code:

node {
  checkout scm
  echo 'hi!'
}

Now I might try to implement changelog generation even in lightweight mode—in principle the SCMFileSystem APIs make it possible, though AFAIK this code path is untested. But it would be a fair amount of work for what seems like a corner case so it is not exactly a high priority.

[michaelneale]

@jglick haha yes 2 days - ancient history!

OK I will take a look at this today, seems pretty simple. If that works, makes sense. They are contrived cases. They are only "echo" so they would in theory work on windows (wishful thinking there though).

[jglick]

they would in theory work on windows

checkout scm should be safe on Windows too. But rather than guess, why not patch your own Jenkinsfile to run your tests on the label windows, which ci.jenkins.io supports?

[michaelneale]

@jglick we aren't yet running on ci.jenkins.io - but a dogfood instance, but otherwise yes. What we are planning is some windows + browser permutations first before building js on windows (I believe it can work though, but its more of a pain than it should be with npm).

[vivek]

@jglick yeah, we will fix the test to do that and upgrade to workflow-multibranch 2.13. thanks.

There is context to that, the upgrade to 2.13 was reverted in this PR because the test failure was recorded as regression, see https://issues.jenkins-ci.org/browse/JENKINS-42525. We will take care of it in another PR.