-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding 2.190.x line #110
Adding 2.190.x line #110
Conversation
…, need to work around jenkinsci/jenkins#4118 when declaring a new LTS baseline.
Hmm, there are test failures but they are not getting reported:
which looks like |
I also saw
recently in this PR (build 2), again a case of an owner field not being updated from a |
Hoping the resolution of INFRA-2283 unblocks this. |
Finally got in results, with a bunch of PCT failures. |
May I suggest incorporating this type of plugin compatibility testing into the official Jenkins LTS release process? In other words, why not do this type of testing before an LTS line is released rather than after the fact? As an end user, I'd feel more comfortable upgrading to a given LTS release knowing that essential plugins (including Pipeline) have been tested with it. |
Yes! I could have filed a draft PR like this one as soon as the LTS line is announced, just building against the weekly baseline. |
· working around jenkinsci/branch-api-plugin#167 · jenkinsci/jenkins#4120 is in 2.190.x · so is jenkinsci/jenkins#4099
I wrote PipelineTest.globalDecoratorAnnotator, so I started looking into this failure. The 500 Server Error was caused by this stack trace:
Reading the changelog, I see the following:
I'm not quite sure what to make of all of this yet, perhaps because I am unfamiliar with how split plugins work. I read this documentation, which led me to I set aside any latent questions about why
This triggered the following error while building the sample project:
Now here's where I am starting to get really confused. Running I decided to investigate whether my suspicion was correct, so I started reading Before I dive into |
I already started trying to deal with the Trilead split, for another plugin. Might not have pushed that yet. I have some ideas, but anyway CI is down again so this is on the back burner. |
Also occurs to me that deleting all record of plugin splits as in Lines 31 to 34 in 6d7fa6e
WEB-INF/detached-plugins/*.hpi .
|
That makes sense to me. I suppose that points to an implementation where we remove from |
Uhh a green build |
@jglick you able to take a look and check you're happy with the tests I ignored for this to work? I'll adjust the PRs to the flakey components soon, and I don't know how to fix the cloudbees-folder or trilead-api issues, but I moved them to ignored so we can hopefully move on with our lives |
Huh, seems I cannot request myself as a reviewer on my own PR… |
(I should have closed this and refiled as an origin branch PR as soon as I stopped active work on it, I guess.) |
maybe that will do ^ otherwise I can re-submit if you want |
I will try to deal with this soon. |
ping 😄 😉 |
@jglick Any thing to do here? |
Yes, I need to review it and push out a release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would vote for merging it to unblock further changes. Tests could be fixed later, BOM is a best-effort test coverage anyway
No. Without green test runs we have no way of knowing what is or is not safe to merge here. |
…uecomment-611178939
…30#issuecomment-611181851
This reverts commit 77183ce. No core BOM is available for the 2.150.x line it seems.
rm -fv pct-work/workflow-support/target/surefire-reports/TEST-org.jenkinsci.plugins.workflow.support.pickles.serialization.SerializationSecurityTest.xml | ||
rm -fv pct-work/workflow-durable-task-step/target/surefire-reports/TEST-org.jenkinsci.plugins.workflow.steps.durable_task.ShellStepTest.xml | ||
rm -fv pct-work/workflow-durable-task-step/target/surefire-reports/TEST-org.jenkinsci.plugins.workflow.support.steps.ExecutorStepTest.xml | ||
rm -fv pct-work/workflow-cps/target/surefire-reports/TEST-org.jenkinsci.plugins.workflow.cps.FlowDurabilityTest.xml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timja I do see flakes here but did you try to track this down?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FlowDurabilityTest.testCompleteAndLoadBuilds expected:<...ne] End of Pipeline
[]> but was:<...ne] End of Pipeline
[Finished: SUCCESS
]>
specifically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure it’s been a long time since I looked at these flakes
Jesse Glick noted that some flaky pipeline tests in other plugins could be resolved by switching from assertLogContains to waitForMessage. Since the git plugin has shown a tendency to flaky tests on Windows, let's use Jesse's recommendation as well. See jenkinsci/bom#110 (comment)
No description provided.