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
Update builds: Refactoring, Parallel test support, Coverages, etc. #21
Update builds: Refactoring, Parallel test support, Coverages, etc. #21
Conversation
@oleg-nenashev This work looks really interesting, assuming it's working, are there any reasons not to merge this before you check off those other two checkboxes? |
@rtyler It works even now (on https://github.com/oleg-nenashev/demo-jenkins-config-as-code). The main problem in the current implementation is that the Maven plugin build will require an extra It is not very efficient, but I want to keep Gradle projects running without breakages. So I consider adding a hack, which would fallback to Gradle from a Maven project if there is no pom.xml. In such case we would be able to keep Generally I had a plan to get CI for |
//TODO: probably it makes sense to default to Maven instead | ||
if (projectType == null) { | ||
stage("Determine the project type") { | ||
timeout(10) { |
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.
@rtyler The code below is my main concern about the current impl
CC @reviewbybees |
@oleg-nenashev Very belated reply: Blue Ocean don't and apparently will not support nested parallels. Bismuth does, explicitly, because I'd anticipated it -- but AFAICT nobody has offered visualization of such structures. Wacky things may happen with nesting of parallels :-/ |
I’m interested in progress on the code coverage front - I’ve thought for some time that plugins in the Jenkins project should have access to a standardised coverage reporter out of the box (if they want it), rather than individual plugin authors having to set up their own SaaS coverage reporter every time. How close are you to enabling support for Jacoco / Cobertura reports? |
Please see https://jenkins.io/blog/2018/08/17/code-coverage-api-plugin-1/ .
Unifying Code coverage reporters was one of the projects during GSoC 2018.
All APIs are there now, but some plugin integrations are needed
…On Mon, Jun 3, 2019, 18:39 Chris Kilding ***@***.***> wrote:
I’m interested in progress on the code coverage front - I’ve thought for
some time that plugins in the Jenkins project should have access to a
standardised coverage reporter out of the box (if they want it), rather
than individual plugin authors having to set up their own SaaS coverage
reporter every time.
How close are you to enabling support for Jacoco / Cobertura reports?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21?email_source=notifications&email_token=AAW4RIENLZRMFLFCN3M5BDDPYVCM3A5CNFSM4EGPDZNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWZ7OYY#issuecomment-498333539>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAW4RICIN32XD3JOUGSE3LDPYVCM3ANCNFSM4EGPDZNA>
.
|
Hello 👋 Of course, feel free to reopen if you are still working on it. Many thanks for the contribution proposal! |
This is a WiP pull request, which updates the Pipeline library a bit. My main idea is to have a more comprehensive Pipeline library demo, which also offers more features on jenkins.io.
repoType
parameter, which enforces Maven or Gradle without doing the repo checkout. IdeallybuildMavenPluginPom()
should fallback to radle so there will be no extranode()
block in the default logicjacoco
support forCoverage publishing, which is supported OOTB in Plugin POMsPipeline for a single platform:
Multi-platform Pipeline:
Multi-platform Pipeline with parallel tests:
The latter graph looks strange, CC @abayer @svanoort. I'd guess BlueOcean does not support parallel-in-parallel.