This is an awesome improvement over having to resolve the PR locally,
suspect it only works for simple PR changes.
Workflow is as follows:
a) create a PR, eg.,
Why does this PR not have a link to the jenkins build and a green/red
flag marker from the result ?
I thought that was the whole reason why we went and granted the jenkins
user access to push to this repo ?
b) wait a few minutes for the build to start, eg.,
c) when the build is done, check the output for a blue ball and p2diff
reports that show nothing unexpected
d) send email to jbosstools-dev@, eg.,
e) wait until PR review is done (eg., 2 days); apply PR and kick the
job to build it and publish it to the usual place
When I moved us to M7, there were a number of required small tweaks
I had a PR that worked, and that validation happens much more
on local than by submitting it off to Jenkins to build. And that
contained bad changes like the addition of jetty 9.3.6 and a newer
Wikitext version. Neither of these were caught by the TP
process -- they were caught by downstream install-grinder and
So, this isn't foolproof, but it's still a huge improvement!
On Tue, May 10, 2016 at 4:16 AM, Max Rydahl Andersen
> or give a link to a PR to see the results (both with good and bad
> This sounds awesome. Any chance you could screencast or screenshot
> workflow ?
> Hi all,
> With https://issues.jboss.org/browse/JBIDE-22312
, a new CI job 
> validates, mirror and runs p2diff  automatically whenever a pull
> is submitted against the jhttps://
> automated validation then report its success or failure on the pull
> directly, annotating it like Travis CI does (with a green or red box
> depending on success).
> It returns a failure if TP validation or mirroring fail. It's most
> to happen because of a wrong reference to a p2 repository, a missing
> IU or
> an incorrect version, or a missing requirement.
> It returns a successful build if it managed to validate the PR and
> its content. In such case, there is still need to follow the links to
> jenkins job have a human look at the p2diff attached to the build,
> and to
> comment whether p2diff looks fine on the PR. Then, when build is
> and p2diff looks good, the PR can be announced to the team and
> for a merge.
> * p2diff report is now generated automatically on regular Maven build
> (even local ones), building the TP with the -Pmultiple2repo profile.
> * Triggering validation build is setup as a cron running every 5
> so it's fine if the build doesn't start immediately after your PR
> creation/update. Just check it again a bit later and in case of
> issue, ping
> @mickaelistria and/or @nickboldt on this PR
> * The validation build takes about 1 hour. There are for sure
> opportunities to speed it up, but as the TP process is slow anyway
> and that
> this approach is already faster than the previous ones requiring
> mirror and p2diff, speeding it up isn't high priority at the moment.
>  https://issues.jboss.org/browse/JBIDE-22308
> Mickael Istria
> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
> My blog <http://mickaelistria.wordpress.com>
- My Tweets
> jbosstools-dev mailing list
> jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio