Simplify the process of using prereleases for testing in a PR

[azeey]

Currently, we have to create a PR against gzdev in order to use prereleases for the libraries needed by the PR. It would be nice if gzdev could also read a file in the root of the library repo (e.g., gz-sim/.ci/repository.yaml) with a similar format as repository.yaml and merge that with its own repository.yaml giving precedence to the settings found in the library repo. For example, if I want to use a prerelease of sdformat12 for testing my gz-sim PR, I would just add

projects:
    - name: sdformat12
      repositories:
          - name: osrf
            type: prerelease

in gz-sim/.ci/repository.yaml. Once the PR is tested with the prerelease, we would make a stable release of sdformat and remove this file from the PR.

This is just a suggestion. I'm open to other ideas to make it easier to do testing with prereleases. Ideally, it would be something that would be included/modified in the PR we're testing, not in gzdev or elsewhere.

[scpeters]

I think it would be easy enough to add a GZDEV_USE_PRERELEASE or GZDEV_USE_NIGHTLY empty file similar to the COLCON_IGNORE files either in the root of the repository or in the .github/ci/ folder. We can update the actions and Jenkins CI scripts to check for this file

[azeey]

If it's safe to use all prereleases or all nightlies, as opposed to just the relevant ones for the PR, then what @scpeters recommended is much easier.

With either of the approaches, I'd suggest we create some sort of merge protection rule to prevent accidental merging while these files are present. One way would be to create a github action job that fails if any of these files are present and making that a required job for merge.

[scpeters]

If it's safe to use all prereleases or all nightlies, as opposed to just the relevant ones for the PR, then what @scpeters recommended is much easier.

we don't currently have a mechanism to specify which dependencies should be installed from stable / prerelease / nightly. For a given project, you are just able to select which sources on packages.osrfoundation.org it can install from. The gzdev plugins/config/repository.yaml file is a centralized collection of configurations for different packages, and the GZDEV_USE_* files would be a distributed approach, but with the same limitations.

[scpeters]

With either of the approaches, I'd suggest we create some sort of merge protection rule to prevent accidental merging while these files are present. One way would be to create a github action job that fails if any of these files are present and making that a required job for merge.

this is a good idea

[scpeters]

initial prototype in gazebo-tooling/action-gz-ci#65

[j-rivero]

Elaborating a bit more on the general context of the proposed feature:

• We probably want to support the use cases of testing a PR in Github actions and Jenkins.
• Generally most of the cli tools uses environment variables to control somehow the configuration in extension to cli parameters and configuration files. This issues is a bit special since probably the easiest for controlling gzdev configuration from a PR is to handle configuration files somehow.
• We will need a way of restricting the configuration to the scope of the PR to avoid possible problems with the carry of PR configurations out of the scope of the PR. To identify a PR, we can use the whole URL or the Github org/repo + PR.
• If possible, support the feature without having to adapt the existing or future code in the CI systems (i.e: release-tools, gz-tooling/ci)

A more complicated idea to add to the option of adding "overlays" configuration yaml or having custom files in some expected places could be to tell to gzdev that a given version of a dependency is needed (or parse CMakeLists.txt for them):

projects:
    - name: sdformat12
      depends:
         - debname: libignition-math7-dev
           version: 7.1.0

and leave the tool to detect with repo is needed. I don't think that we want this since the control of dependencies in the stable repository is a highest goal probably so we would require explicit repository control.