One github repo, two pipelines, two distinct checks in github?

[Ian Smith]

Hi,

Can anyone confirm if the github web hook to Jenkins multibranch pipeline is a 1:1 mapping only, or if it can be 1:n?

What I want to be able to do is

• On an update to a PR trigger two pipelines
• One runs a code validation check using unit tests
• The other deploys the code to a staging server and runs system level tests
• I have distinct files for these two plugins, and using 2.15 of pipeline:multibranch plugin I can see that an update to a PR triggers both pipelines
• Once the unit test has finished one check is added to the PR view on github
• Once the system level test is finished a separate check is added to the PR view on github

What I'm seeing is only one check appear. If the unit test passes, then a green tick is seen. However if the system level test fails then the green tick is then overwritten.

Is it possible to define two checks relating to the two pipelines in use?

This is slightly related to the post at https://groups.google.com/forum/#!msg/jenkinsci-users/TRwnoU6_MOU/p5rdw2bOBgAJ

Thanks, Ian

[Ann B]

Hi Ian-

I'm sorry that I cannot answer your question directly, as we do not use a web hook.

Have you thought of posting to the github statuses api - https://developer.github.com/v3/repos/statuses/#create-a-status with a separate link for each of your pipelines?   We kick off all of our pipeline jobs in parallel (static, functional, unit, etc).  Each job adds a Statuses link to the PR with an initial value of 'Pending' with a link to the running job in jenkins.  As each parallel job finishes, it updates the PR Status with 'Failed' or 'Passes'.

Ann

[Ian Smith]

Hi Ann,

Thank you for that information. Sadly this isn't a viable option due to two reasons

1. Having to embed the Github user token in the curl command, which means adding that to the Jenkinsfile script
2. The webhook still takes the value of the build state for the last pipeline. So although I can define separate values and I see three check marks in the PR in github, if the second pipeline marks the build as a failure then the pr-merge status is also set to failure.

Kind regards, Ian

[Richard Bywater]

With regards to 1, the credentials and credential binding plugins would probably help out there as you wouldn't have to embed the token in the script.

Can't comment on the other issues though.

Richard

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/a662c5ae-5c92-40ac-9169-9446477d9f60%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Smith]

Hi Richard,

Thank you for that suggestion. Checked that we did have those plugins installed and then came across withCredentials in the pipeline syntax. After adding that I'm now able to pull out the access token from the Jenkins credentials without it appearing in plain text.

Regarding the second point, I think this just how Github works unfortunately, and comes back to the assumed 1:1 mapping. To be fair there is no real way that github can know the infrastructure on a remote Jenkins site to know that a commit could have multiple replies. In an ideal world it would be nice if the pr_merge did a logic AND to any replies it sees, but I can see that this could cause other issues. By using the status API at least it is possible for each pipeline to indicate it's own individual status.

Ian