Should build.gimp.org be retired?
History
When I began maintaining Jenkins I asked the GIMP dev team about keeping CI/CD files in the GIMP source repository to give them more control and ease on updating the CI process and manage dependencies. At the time, the idea was rejected because the core dev team wanted to keep meta-data files related to CI out of the GIMP repository.
Jenkins is also not well integrated with GitLab merge requests. Some context can also be read in #950 (closed)
See also documentation for the existing Jenkins system.
Now
It seems the GIMP team is moving to GitLab's autodevops and putting files for building GIMP in GitLab CI within the GIMP source code repository. This is great and it simplifies updating the CI process for GIMP builds.
There haven't been much contributions to the CI repositories related to Jenkins other than myself. Any time builds in Jenkins would break, often it would require me to make the changes (any GIMP devs could but it just ended up this way). Broken builds tends to be a side affect of the CI process not being integrated with merge requests.
By using GitLab CI in its current form, builds shouldn't break on master branch because a broken build will block someone from merging code via merge-request.
Question
Should we consider completely decommissioning https://build.gimp.org/ ? If not, what value is it adding that it should stay around?
@Jehan mind chiming in since you're integrating autodevops?