Jenkins 2.46.3 LTS RC testing started

44 views
Skip to first unread message

Oliver Gondža

unread,
May 11, 2017, 6:31:35 AM5/11/17
to jenkin...@googlegroups.com
Hello everyone,

Latest LTS RC was made public and it is ready to be tested. Release is
scheduled for 2017-05-24.

Report your findings in this thread or on the test plan wiki page.

Download bits from
http://mirrors.jenkins-ci.org/war-stable-rc/2.46.3/jenkins.war
Check community maintained LTS test plan
https://wiki.jenkins-ci.org/display/JENKINS/LTS+2.46.x+RC+Testing

Thanks
--
oliver

Oleg Nenashev

unread,
May 22, 2017, 5:32:43 AM5/22/17
to Jenkins Developers
I do not see any issues on my instance so far.
Likely it's good to go on Wednesday

BR, Oleg

четверг, 11 мая 2017 г., 12:31:35 UTC+2 пользователь ogondza написал:

ogondza

unread,
May 24, 2017, 8:41:42 AM5/24/17
to Jenkins Developers
ATH has captured a regression[1] in .3 I am investigating right now. Compared to .2 it seems to pick workflow-job 2.12 (instead of 2.11) that fails to load as it requires Jenkins 2.60+.

[1] https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness-stable/1492/testReport/core/InstallWizardTest/wizardInstallSugestedTest/
[2]
```
INFO: Attempting to dynamic load /home/ogondza/code/jenkins/acceptance-test-harness/jhrevert/plugins/workflow-job.jpi
May 24, 2017 2:29:43 PM hudson.model.UpdateCenter$DownloadJob run
SEVERE: Failed to install Pipeline: Job
java.io.IOException: Failed to dynamically deploy this plugin
    at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1899)
    at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1656)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Failed to install workflow-job plugin
    at hudson.PluginManager.dynamicLoad(PluginManager.java:875)
    at hudson.PluginManager.dynamicLoad(PluginManager.java:814)
    at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1895)
    ... 5 more
Caused by: java.io.IOException: Pipeline: Job v2.12 failed to load.
 - You must update Jenkins from v2.46.3-SNAPSHOT (private-05/24/2017 12:25 GMT-ogondza) to v2.60 or later to run this plugin.
    at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:621)
    at hudson.PluginManager.dynamicLoad(PluginManager.java:865)
    ... 7 more
```

Jesse Glick

unread,
May 24, 2017, 9:16:41 AM5/24/17
to Jenkins Dev
On Wed, May 24, 2017 at 8:41 AM, ogondza <ogo...@gmail.com> wrote:
> Compared to .2 it seems to pick workflow-job 2.12 (instead of 2.11) that
> fails to load as it requires Jenkins 2.60+.

I had noticed a similar failure yesterday but did not dig into it, in
a test requesting `workflow-job@2.0` among others.

Skipping sshGitInsideDocker(plugins.WorkflowPluginTest)
org.junit.internal.AssumptionViolatedException: Unable to install
required plugins
at org.jenkinsci.test.acceptance.junit.WithPlugins$RuleImpl$1.installPlugins(WithPlugins.java:178)
at org.jenkinsci.test.acceptance.junit.WithPlugins$RuleImpl$1.evaluate(WithPlugins.java:129)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.jenkinsci.test.acceptance.junit.JenkinsAcceptanceTestRule$1$2$1.evaluate(JenkinsAcceptanceTestRule.java:177)
at org.jenkinsci.test.acceptance.junit.FilterRule$1.evaluate(FilterRule.java:63)
at org.jenkinsci.test.acceptance.junit.WithDocker$RuleImpl$1.evaluate(WithDocker.java:50)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.jenkinsci.test.acceptance.junit.JenkinsAcceptanceTestRule$1.evaluate(JenkinsAcceptanceTestRule.java:60)
at …
Caused by: org.jenkinsci.test.acceptance.update_center.UpdateCenterMetadata$UnableToResolveDependencies:
Unable to install PluginMetadata[workflow-job,2.12] plugin because of
core dependency. Required: 2.60 Used: Jenkins(http://127.0.0.1:62670/)
at org.jenkinsci.test.acceptance.update_center.UpdateCenterMetadata.transitiveDependenciesOf(UpdateCenterMetadata.java:88)
at org.jenkinsci.test.acceptance.po.PluginManager.installPlugins(PluginManager.java:193)
at org.jenkinsci.test.acceptance.junit.WithPlugins$RuleImpl$1.installPlugins(WithPlugins.java:176)
... 23 more

But I was running against 2.46.2 (with ATH as of `master` yesterday),
so this does not seem like a regression in .3; rather, a problem with
the update center? But

https://github.com/jenkins-infra/backend-update-center2/blob/5c0a4a1ae6ea58cb94265a772e65548c8251564f/site/generate.sh#L7

looks right, and
https://gist.github.com/jglick/0a85759ea65f60e107ac5a85a5032cae checks
out:

$ uc-grep workflow-job 2.46.2
2.11

so that does not explain my failure, which feels like an ATH bug. OTOH while

$ uc-grep workflow-job 2.46.3
2.11

is right,

$ uc-grep workflow-job 2.46.3-SNAPSHOT
2.12

looks to be a bug in the update center (failing to match more exotic
version strings; FWIW http://jenkins-updates.cloudbees.com/ gets it
right) that *would* result in ATH failures when testing a nonreleased
build.

So maybe there are *two* infrastructure bugs here? Will leave it you
to drive the investigation unless you think you need some assistance.

Oliver Gondža

unread,
May 24, 2017, 9:23:32 AM5/24/17
to jenkin...@googlegroups.com
You are onto something, Jesse. I was somehow surprised to find out it
started to appear in "6bcd968e9f397d508f7c75dd6c38f9189ef9cdef
[maven-release-plugin] prepare for next development iteration" commit
with nothing interesting in it. The problem seems to be the -SNAPSHOT
version of jenkins, I have just successfully retested that the same
changes with version "2.46.3" are fine.

My next hypothesis is the infra is point (LTS) snapshots to latest(?) UC.
--
oliver

Daniel Beck

unread,
May 24, 2017, 9:30:23 AM5/24/17
to jenkin...@googlegroups.com

> On 24. May 2017, at 15:23, Oliver Gondža <ogo...@gmail.com> wrote:
>
> My next hypothesis is the infra is point (LTS) snapshots to latest(?) UC.

You're right. From the .htaccess that redirects requests to the tiered update sites:

> # If we have a match that looks like an LTS version, e.g. 1.554.1, redirect to stable-1.554
> RewriteCond %{QUERY_STRING} ^.*version=([0-9]*\.[0-9]*)\.[0-9]*$ [NC]
> RewriteCond %{DOCUMENT_ROOT}/stable\-%1%{REQUEST_URI} -f
> RewriteRule ^update\-center\.[json|html]+ /stable\-%1%{REQUEST_URI}? [NC,L,R=301]

The first RewriteCond does not allow non-numeric suffixes.

Anyone here speak fluent mod_rewrite and can file a PR for this?

https://github.com/jenkins-infra/backend-update-center2/blob/5c0a4a1ae6ea58cb94265a772e65548c8251564f/site/static/.htaccess#L7

Jesse Glick

unread,
May 24, 2017, 9:32:03 AM5/24/17
to Jenkins Dev
On Wed, May 24, 2017 at 9:23 AM, Oliver Gondža <ogo...@gmail.com> wrote:
> I have just successfully retested that the same changes with
> version "2.46.3" are fine.

Hmm, so I wonder why I got a similar failure using 2.46.2. Maybe I was
using a cached UC JSON in `/tmp` from a dev build somehow? But IIRC
the cache is only good for a day, and I did not recently run tests
against dev cores AFAIK.

> My next hypothesis is the infra is point (LTS) snapshots to latest(?) UC.

https://github.com/jenkins-infra/backend-update-center2/blob/5c0a4a1ae6ea58cb94265a772e65548c8251564f/site/generate.sh#L72
is wrong I think. Unfortunately there seem to be no automated tests in
this repo that cover the proxy redirect rules, which is bad because
these are absolutely critical to the functioning of the site without
serious user errors, and they could easily be broken by minor
mistakes.

Oliver Gondža

unread,
May 24, 2017, 9:39:56 AM5/24/17
to jenkin...@googlegroups.com
On 2017-05-24 15:31, Jesse Glick wrote:

>> My next hypothesis is the infra is point (LTS) snapshots to latest(?) UC.
>
> https://github.com/jenkins-infra/backend-update-center2/blob/5c0a4a1ae6ea58cb94265a772e65548c8251564f/site/generate.sh#L72
> is wrong I think. Unfortunately there seem to be no automated tests in
> this repo that cover the proxy redirect rules, which is bad because
> these are absolutely critical to the functioning of the site without
> serious user errors, and they could easily be broken by minor
> mistakes.

Not that I understand much of the infra automation, but Daniel's
suggestion sounds better than this. IFAICT the regexp will look like
`^.*version=2.(\d+)$` - which is weekly.

Is there any infra testsuite where this tests should reside? Sound
trivial to implement ...

--
oliver

Jesse Glick

unread,
May 24, 2017, 10:03:13 AM5/24/17
to Jenkins Dev
On Wed, May 24, 2017 at 9:39 AM, Oliver Gondža <ogo...@gmail.com> wrote:
> Daniel's suggestion
> sounds better than this.

I think we had the identical suggestion, though he was linking to the
generated file (why is this committed to SCM??) while I was linking to
the source file.

> Is there any infra testsuite where this tests should reside? Sound trivial
> to implement ...

Well this repository does have some tests, just none suitable for this
purpose. I have no idea if there are more useful integration tests
elsewhere. A question for #jenkins-infra I suppose.

Daniel Beck

unread,
May 24, 2017, 10:15:04 AM5/24/17
to jenkin...@googlegroups.com

> On 24. May 2017, at 16:03, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> though he was linking to the
> generated file (why is this committed to SCM??) while I was linking to
> the source file.

Not true. The LTS rule I link to is static (it uses the shortcut of "client reported version has a matching update site"), only the weekly tiers are dynamically added (as it's not as easy for those).

Jesse Glick

unread,
May 24, 2017, 12:56:29 PM5/24/17
to Jenkins Dev
On Wed, May 24, 2017 at 10:14 AM, Daniel Beck <m...@beckweb.net> wrote:
> Not true. The LTS rule I link to is static

Then why does the file start with

# THIS FILE IS GENERATED

Am I missing something?

Daniel Beck

unread,
May 24, 2017, 1:12:17 PM5/24/17
to jenkin...@googlegroups.com

> On 24. May 2017, at 18:56, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Then why does the file start with
>
> # THIS FILE IS GENERATED
>
> Am I missing something?

Because that way nobody tries to edit it manually on the box the finished file gets rsynced to. E.g. Puppet adds a similar comment to config files it manages.

Here's the finished generated file (from trusted.ci, we don't run the shell script on ci.j.io):
https://gist.github.com/daniel-beck/2a1a275d3eb4ff04a93dac2e6c1c5473

R. Tyler Croy

unread,
May 24, 2017, 3:24:33 PM5/24/17
to jenkin...@googlegroups.com
(replies inline)

On Wed, 24 May 2017, Jesse Glick wrote:
This repository runs some very high level tests against production
infrastructure: <https://github.com/jenkins-infra/acceptance-tests>




- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
signature.asc

Oliver Gondža

unread,
May 25, 2017, 4:22:54 AM5/25/17
to jenkin...@googlegroups.com
On 2017-05-24 21:24, R. Tyler Croy wrote:

> This repository runs some very high level tests against production
> infrastructure: <https://github.com/jenkins-infra/acceptance-tests>

Thanks: https://github.com/jenkins-infra/acceptance-tests/pull/1

--
oliver
Reply all
Reply to author
Forward
0 new messages