Hello,
Following the official entrance of GNOME Release Service into production as the only way to perform a module release via GitLab CI (read more) some concerns were raised regarding how to correctly configure the CI pipeline without having to test it “in production.” To address this, a sandbox environment was created.
This sandbox behaves exactly the same way as the official, with the exception of NOT denying requests from pipelines from projects outside of GNOME or Incubator groups, meaning you can fork the official project, try to set up the new release process exactly as explained in Handbook - Making a Release and create your own “debug release” of the module. The only change you need to make from the example of .gitlab-ci.yml setup is to use a release-service-sandbox branch instead of master for the CI component.
Demonstration:
include:
- component: gitlab.gnome.org/GNOME/citemplates/release-service@release-service-sandbox # <-- instead of @master
# nothing else to change
To get feedback on how the “debug release” went you can:
- monitor the output of the release job (be aware that any
auth_errorsthat could be returned with a message about the release being successful would be the reason why the call to the GNOME Release Service would fail in production) and - after the job finishes look for the release at sandbox simple file system server that has the same structure as Index of /sources/.
Mind you that, as this is a sandbox environment, no changes are supposed to be persistent and you should use this only as a way to test out your release procedure before utilizing it in production if needed.
Hope the sandbox environment helps you test and fine-tune your release process with confidence.
Thanks,
Stefan