| Re: [cross-project-issues-dev] [epp-dev] EPP 2020-06 M2 |
Mickael,
Yes, in principle it could be made to do that. It uses the same
underlying infrastructure (a giant bloated class) as is used for
the general repository analyzer and that generates "test results":
https://ci.eclipse.org/oomph/job/repository-analyzer/lastBuild/
So the SimRel analyzer too could be made to generate a test report and fail when tests fail. Ideally the overall SimRel report would have no red markers:
https://download.eclipse.org/oomph/archive/simrel/index.html
Though it's of course possible to lower the bar so that the
provider not be Eclipse.* and broken branding links wouldn't cause
a failures, but to be really frank, I'm quite frustrated with the
fact that such problems can linger indefinitely:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=552634
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553881
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559782
The job takes about 17 minutes to run
https://ci.eclipse.org/oomph/job/simrel-analyzer/
And that would be much slower if it didn't have a persistent workspace in which it can and does cache the artifacts in order to analyze them in detail.
Regards,
Ed
On Thu, May 7, 2020 at 12:28 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:
Or better yet, it could be done as part of verifying the SimRel contribution...
That would be ideal.Is the Oomph report generator able to fail (ie return non-0) when one of its rule is broken for a repo? If so, it would be straightforward to plug that a a "verify" step on CI, similarly to https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/tree/pom.xml#n132 . I may be able to dedicate some time to this in a couple of weeks.
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev