dune-buildbot issueshttps://gitlab.dune-project.org/quality/dune-buildbot/-/issues2018-06-16T06:17:36Zhttps://gitlab.dune-project.org/quality/dune-buildbot/-/issues/12Setup a mock set of repositories2018-06-16T06:17:36ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deSetup a mock set of repositoriesOf core modules and pdelab for testing.Of core modules and pdelab for testing.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/11Possbile Scheduler / Change sources2018-06-16T06:17:37ZTimo KochPossbile Scheduler / Change sources* In a merge request based worflow, a merge request _and_ follow-up commits trigger testing of the to-be-merged branch (for core-modules: in all core-modules).
* Change source can be web-hooks (only accessible to administrators) and c...* In a merge request based worflow, a merge request _and_ follow-up commits trigger testing of the to-be-merged branch (for core-modules: in all core-modules).
* Change source can be web-hooks (only accessible to administrators) and change logs on a mailing list that a buildbot can suscribe to (publicly available).
* Additionally nightly, weekly, and forced (manually triggered/retriggered) schedulers are of interest.
* For downstream user modules it can also be important to use receive change logs on push-to-master actions in the core modules.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/10General structure of the dune-buildbot2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deGeneral structure of the dune-buildbotThe repository should adhere to the following guide lines:
* It should only contain a python package `dune.buildbot`.
* The folder `dune/buildbot` should contain subdirectories that match
the subdirs at https://github.com/buildbot...The repository should adhere to the following guide lines:
* It should only contain a python package `dune.buildbot`.
* The folder `dune/buildbot` should contain subdirectories that match
the subdirs at https://github.com/buildbot/buildbot/tree/master/master/buildbot
* It should export a `create_master` script that supersedes `buildbot create-master`
and configures a master from `ini` or `cfg` input.
This task can be closed once all existing content is brought into shape.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/9`dune_create_buildbot_master` script2018-06-16T06:17:37ZTimo Koch`dune_create_buildbot_master` scriptdune-buildbot should contain a script that wraps the call
```
buildbot create-master <name>
```
then cleans up all unused files. Then creates (possibly from templates `master.cfg.template`, `buildbot.tac.template`) the config file `...dune-buildbot should contain a script that wraps the call
```
buildbot create-master <name>
```
then cleans up all unused files. Then creates (possibly from templates `master.cfg.template`, `buildbot.tac.template`) the config file `master.cfg` and `buildbot.tac` using input from an external `master.ini` file. The script can be called inside a docker / or outside to setup the master before startup.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/8Automated dependency/influence detection for modules in a master setup (User ...2018-06-16T06:17:37ZTimo KochAutomated dependency/influence detection for modules in a master setup (User Module)entries in the `master.ini` could look like
```ini
# list of modules to test
[modules]
dune-mymodule = git://...
```
the `dune_create_buildbot_master` script uses the repository to deduct dependencies and influence path for e.g. th...entries in the `master.ini` could look like
```ini
# list of modules to test
[modules]
dune-mymodule = git://...
```
the `dune_create_buildbot_master` script uses the repository to deduct dependencies and influence path for e.g. the core modules in order to trigger
dune-grid change -> triggers testing of dune-mymodule
automatically.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/7Generate a master configuration from an ini file2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deGenerate a master configuration from an ini fileInstead of directly providing a `cfg` and `tac` file, `dune-buildbot` should generate these from a simple configuration ini file. The accepted keys in that inifile should be well documented in a central place. Instead of directly providing a `cfg` and `tac` file, `dune-buildbot` should generate these from a simple configuration ini file. The accepted keys in that inifile should be well documented in a central place. https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/6Add support for updating docker registries2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deAdd support for updating docker registriesThe buildmaster should have a mechanism to retrigger the docker builds on registries used for testing.The buildmaster should have a mechanism to retrigger the docker builds on registries used for testing.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/5Use a webhook as a ChangeSource2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deUse a webhook as a ChangeSourceIntegrating with `gitlab.dune-project.org`...
In the long run, we also want to parse tags from the MR and customize builds by that information.Integrating with `gitlab.dune-project.org`...
In the long run, we also want to parse tags from the MR and customize builds by that information.https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/4Implement Dune-specific Build Steps2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deImplement Dune-specific Build StepsBuildsteps should be:
* `DuneGit`
* `DuneConfigure` (`DuneCMake`?)
* `DuneNinja`
* `DuneNinjaBuildTests`
* `DuneCTest`Buildsteps should be:
* `DuneGit`
* `DuneConfigure` (`DuneCMake`?)
* `DuneNinja`
* `DuneNinjaBuildTests`
* `DuneCTest`https://gitlab.dune-project.org/quality/dune-buildbot/-/issues/3Implement a SlurmLatentBuildSlave2018-06-16T06:17:37ZDominic Kempfdominic.kempf@iwr.uni-heidelberg.deImplement a SlurmLatentBuildSlaveA LatentBuildSlave, that submits a job into a queueing system. The job - once allocated the ressources - starts up a build slave. This buildslave is potentially run in a docker container.A LatentBuildSlave, that submits a job into a queueing system. The job - once allocated the ressources - starts up a build slave. This buildslave is potentially run in a docker container.Dominic Kempfdominic.kempf@iwr.uni-heidelberg.deDominic Kempfdominic.kempf@iwr.uni-heidelberg.dehttps://gitlab.dune-project.org/quality/dune-buildbot/-/issues/2Make test labels depend on what the build trigger is2018-06-16T06:17:37ZTimo KochMake test labels depend on what the build trigger isBuild triggered by a repo change should probably run ctests with label CONTINUOUS
and a build triggered by the nightly scheduler with NIGHTLY. We don't want separate builders, so
the buildstep ctest has to check from where he was trigg...Build triggered by a repo change should probably run ctests with label CONTINUOUS
and a build triggered by the nightly scheduler with NIGHTLY. We don't want separate builders, so
the buildstep ctest has to check from where he was triggered and set the label accordingly.