... | ... | @@ -6,22 +6,27 @@ As of today there are 1556 repositories at Eclipse. We need to define a good str |
|
|
* Continuously fetch, analyse and publish results for projects.
|
|
|
* Monitor execution, as it sometimes stales (e.g. when encountering a repo that requires credentials, or for whatever reason or bug).
|
|
|
|
|
|
## Options
|
|
|
## Implementation
|
|
|
|
|
|
* Setup a local Jenkins instance to execute runs, and our static website for results. \
|
|
|
Starting a run would be easy thanks to the jenkins UI, with tracking and monitoring of past runs, ability to automatically start jobs, etc.
|
|
|
* Write a dynamic (i.e. with active endpoints e.g. to start runs) frontend, which could be used both for control and reporting. \
|
|
|
Implies some heavy dev.
|
|
|
* Simply rely on crontabs for the update/execution of projects, and use our static website for results. \
|
|
|
Less visible, no easy way to start a run remotely or track job execution..
|
|
|
We sat up (see [this infrazilla issue](https://gitlab.eclipse.org/eclipsefdn/infrazilla/-/issues/617)) a Jenkins local executer on ort-vm1, which is controlled from the [main Jenkins infra](https://foundation.eclipse.org/ci/infra/job/ort/).
|
|
|
|
|
|
## Implementation
|
|
|
The following jobs are defined:
|
|
|
* [run_extract](https://foundation.eclipse.org/ci/infra/job/ort/job/run_extract/) executes the extraction script that reads the logs and publishes the static website on <https://ort-vm1.eclipse.org>.
|
|
|
* [run_ort](https://foundation.eclipse.org/ci/infra/job/ort/job/run_ort/) executes the analysis on a single project, including all its repositories.
|
|
|
* [update_repos](https://foundation.eclipse.org/ci/infra/job/ort/job/update_repos/) gets the full list of repositories from the [Eclipse API](https://www.eclipse.org/projects/export/repositories.csv.php), then creates or updates (pulls) them as needed.
|
|
|
|
|
|
## Notes
|
|
|
|
|
|
Here are a few notes jotted down while working on these:
|
|
|
* Analysis is only done on the main/master branch, as defined when cloning.
|
|
|
* Analysis is only done on the main/master branch, as defined when cloning. We will need to define a strategy to analyse other branches as well.
|
|
|
* Curation files for clearlydefined should be cleaned regularly, e.g. once per month.
|
|
|
|
|
|
### Braimstorming
|
|
|
|
|
|
* Setup a local Jenkins instance to execute runs, and our static website for results. \
|
|
|
Starting a run would be easy thanks to the jenkins UI, with tracking and monitoring of past runs, ability to automatically start jobs, etc.
|
|
|
* Write a dynamic (i.e. with active endpoints e.g. to start runs) frontend, which could be used both for control and reporting. \
|
|
|
Implies some heavy dev.
|
|
|
* Simply rely on crontabs for the update/execution of projects, and use our static website for results. \
|
|
|
Less visible, no easy way to start a run remotely or track job execution..
|
|
|
|