Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CBI/p2repoAnalyzers/Repo Reports"

< CBI
(Added Hudson build location hint)
m
Line 5: Line 5:
 
As one example, the reports or tests are ran against the latest successful Simultaneous Release CLEAN BUILD on Hudson, so can always be viewed there. There is even a link on the Hudson build instance [https://hudson.eclipse.org/simrel/ main page] that links to the [https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html latest report].  In that case, the report is also copied, along with the repository, so it ends up on staging area too, so can be also be viewed under a URL such as for the  [http://download.eclipse.org/staging/neon/buildInfo/reporeports/ staging repository].   
 
As one example, the reports or tests are ran against the latest successful Simultaneous Release CLEAN BUILD on Hudson, so can always be viewed there. There is even a link on the Hudson build instance [https://hudson.eclipse.org/simrel/ main page] that links to the [https://hudson.eclipse.org/simrel/job/simrel.oxygen.runaggregator.BUILD__CLEAN/lastSuccessfulBuild/artifact/aggregation/final/buildInfo/reporeports/index.html latest report].  In that case, the report is also copied, along with the repository, so it ends up on staging area too, so can be also be viewed under a URL such as for the  [http://download.eclipse.org/staging/neon/buildInfo/reporeports/ staging repository].   
  
While many projects have their own, similar tests (which have one way or another have provided the starting point for all these tests) it is worth some effort effort to collect some common tests in a common place to encourage reuse and improvements.  
+
While many projects have their own, similar tests (which have one way or another have provided the starting point for all these tests) it is worth some effort to collect some common tests in a common place to encourage reuse and improvements.  
  
For now, the tests and scripts are in Git repo. To load into workspace, and appropriate URL would be similar to
+
For now, the tests and scripts are in Git repo. To load into workspace, an appropriate URL would be similar to
 
   <code><nowiki>ssh://<userid>@git.eclipse.org:29418/cbi/org.eclipse.cbi.p2repo.analyzers</nowiki></code>
 
   <code><nowiki>ssh://<userid>@git.eclipse.org:29418/cbi/org.eclipse.cbi.p2repo.analyzers</nowiki></code>
  
Line 20: Line 20:
 
In fact, the ultimate goal is that the reports for the simultaneous release common repository are simply a final sanity check and that all projects can perform these tests themselves, early in development cycle. But ... until then, the reports will be ran against, at least, the common staging repositories. Most of the tests can be used, with some copy/paste/hacking directly from an IDEs workbench, against a local repository on your file system. Start small. :)  
 
In fact, the ultimate goal is that the reports for the simultaneous release common repository are simply a final sanity check and that all projects can perform these tests themselves, early in development cycle. But ... until then, the reports will be ran against, at least, the common staging repositories. Most of the tests can be used, with some copy/paste/hacking directly from an IDEs workbench, against a local repository on your file system. Start small. :)  
  
If/when others have fixes, abstractions, or new tests, please open a bug in the [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CBI&component=p2%20Repository%20Analyzers p2 Repository Analyzers] component in bugzilla, so these tests and reports can be improved over time by community effort.  
+
If/when others have fixes, abstractions, or new tests, please open a bug in the [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CBI&component=p2%20Repository%20Analyzers p2 Repository Analyzers] component in Bugzilla, so these tests and reports can be improved over time by community effort.  
  
The code and scripts, as of right now, are oriented towards simply "producing reports". But if you browse the code, you'll see some commented-out code in places that can cause "failed" flags to be set, which would be appropriate for some projects ... and, eventually, even the Simultaneous Release repository. Running the reports are, as of right now, are oriented towards being a simple "ant task". But more recently Dennis Huebner has contributed the framework to run as JUnit tests but that still needs to be documented. See also the -useNewApi flag which produces reports based on "passed", "failed", or "warning". Follow {{bug|487409}} for updating the documentation. There is a bug open to convert to Maven tasks (see {{bug|487468}}).
+
The code and scripts, as of right now, are oriented towards simply "producing reports". But if you browse the code, you'll see some commented-out code in places that can cause "failed" flags to be set, which would be appropriate for some projects ... and, eventually, even the Simultaneous Release repository. Running the reports are, as of right now, oriented towards being a simple "Ant task". But more recently Dennis Huebner has contributed the framework to run as JUnit tests but that still needs to be documented. See also the -useNewApi flag which produces reports based on "passed", "failed", or "warning". Follow {{bug|487409}} for updating the documentation. There is a bug open to convert to Maven tasks (see {{bug|487468}}).
  
 
== Running your own Repository Reports ==
 
== Running your own Repository Reports ==
Line 37: Line 37:
 
that meta data.  
 
that meta data.  
  
Yet another, small class of tests, verify the jars are signed.  
+
Yet another, small class of tests, verify that the jars are signed.  
 
These tests are not really "Java" or "workspace" related, but use Java's "exec" method
 
These tests are not really "Java" or "workspace" related, but use Java's "exec" method
 
to invoke "jarsigner -verify" on multiple threads, on a directory of jars. (There is actually a faster heuristic in the code that simply looks for the presence of the Eclipse signature file, but that is a heuristic and might not always be accurate, so it not used by default).
 
to invoke "jarsigner -verify" on multiple threads, on a directory of jars. (There is actually a faster heuristic in the code that simply looks for the presence of the Eclipse signature file, but that is a heuristic and might not always be accurate, so it not used by default).

Revision as of 05:03, 18 October 2016

p2 Repository Analysis

This page roughly describes collection of automated checks and reports to run against p2 repositories or directories of jars.

As one example, the reports or tests are ran against the latest successful Simultaneous Release CLEAN BUILD on Hudson, so can always be viewed there. There is even a link on the Hudson build instance main page that links to the latest report. In that case, the report is also copied, along with the repository, so it ends up on staging area too, so can be also be viewed under a URL such as for the staging repository.

While many projects have their own, similar tests (which have one way or another have provided the starting point for all these tests) it is worth some effort to collect some common tests in a common place to encourage reuse and improvements.

For now, the tests and scripts are in Git repo. To load into workspace, an appropriate URL would be similar to

  ssh://<userid>@git.eclipse.org:29418/cbi/org.eclipse.cbi.p2repo.analyzers

Or, for casual browsing, see org.eclipse.cbi.p2repo.analyzers.git (browse, stats, fork on OrionHub) .

The project is built as both an Eclipse "product" and as a feature installable from a p2 repository. As of this writing, no "permanent" locations for those (watch bug 506037) but in the meantime can be downloaded or installed from the results of a Hudson build. The Hudson builds and functional testing is done under

https://hudson.eclipse.org/cbi/view/p2RepoRelated/ 

The reports can be ran locally from your workbench or adopted for your own production builds.

In fact, the ultimate goal is that the reports for the simultaneous release common repository are simply a final sanity check and that all projects can perform these tests themselves, early in development cycle. But ... until then, the reports will be ran against, at least, the common staging repositories. Most of the tests can be used, with some copy/paste/hacking directly from an IDEs workbench, against a local repository on your file system. Start small. :)

If/when others have fixes, abstractions, or new tests, please open a bug in the p2 Repository Analyzers component in Bugzilla, so these tests and reports can be improved over time by community effort.

The code and scripts, as of right now, are oriented towards simply "producing reports". But if you browse the code, you'll see some commented-out code in places that can cause "failed" flags to be set, which would be appropriate for some projects ... and, eventually, even the Simultaneous Release repository. Running the reports are, as of right now, oriented towards being a simple "Ant task". But more recently Dennis Huebner has contributed the framework to run as JUnit tests but that still needs to be documented. See also the -useNewApi flag which produces reports based on "passed", "failed", or "warning". Follow bug 487409 for updating the documentation. There is a bug open to convert to Maven tasks (see bug 487468).

Running your own Repository Reports

Introduction

This section gives a brief outline of how to run the "repo reports" locally, against a repository on your local file system and gives some links to scripts that some projects use "in production".

There are some tests, that look at jars specifically, that require the jars to be on local file system and essentially use plain 'ol Java file IO and regex-type checks on the contents.

Another class of tests, read the content.jar/xml meta-data and reports on the data or relationships in that meta data.

Yet another, small class of tests, verify that the jars are signed. These tests are not really "Java" or "workspace" related, but use Java's "exec" method to invoke "jarsigner -verify" on multiple threads, on a directory of jars. (There is actually a faster heuristic in the code that simply looks for the presence of the Eclipse signature file, but that is a heuristic and might not always be accurate, so it not used by default).

Running the repo tests

These instructions are focused on "running from your workspace", but could also easily be done "from the command line" if you know how to run Eclipse Applications from the command line.

The Basics

The Eclipse Application is named 'org.eclipse.cbi.p2repo.analyzers.repoReport'. It takes two "system properties"; one to specify where you want the output to go, and another to specify where the repository-to-analyze is on the file system. An optional third parameter names a repository to use as reference for the "version check" reports. For example:

  • -DreportOutputDir=/home/shared/eclipse/repoReport
  • -DreportRepoDir=/home/www/html/downloads/eclipse/updates/4.6-M-builds/M20161013-0730/
  • -DreferenceRepo=/home/www/html/downloads/eclipse/updates/4.6/R-4.6.1-201609071200/

There is another parameter, -DuseNewApi=true which is not yet documented (bug 487409) but runs the code in such a way that tests pass, fail, or give a warning, and produces compact, color coded table of results, to link to an experimental example.

Some Details

The source project is named 'org.eclipse.cbi.p2repo.analyzers' and is currently in Git in repository named 'cbi/org.eclipse.cbi.p2repo.analyzers.git'. See org.eclipse.cbi.p2repo.analyzers.git (browse, stats, fork on OrionHub) .

Once you load that project into your workspace, it will include one "launch configuration" that can be used as a starting example, edited and used to launch the application from your workspace.

On a large repository, it take 5 or 10 minutes to complete, and then you just look at the results (usually) with a web browser starting with the 'index.html' at the location you specified in 'reportOutputDir' property.

For one example of a bash script that takes advantage of a "product build" to run the report application, see the example in the Eclipse Platform Git repository named createReports.sh.

For an example of installing as a feature from a p2 repository see the 'installTestsFromRepo' target in the SimRel build.xml file. And then, see the actual running of the tests in the 'runReports' target in the SimRel runTests.xml file.

Getting help or making contributions

You can ask questions on cbi-dev list if the tests do not work as expected. Or, even better, you can make improvements/fixes directly on this wiki, if the instructions can be better. Feel free to supply patches in the p2 Repository Analyzers component in bugzilla.

Back to the top