To me it seems this discussion is quite abstract and there are several misunderstandings because not everybody knows every detail of snap packaging and/or the KDE infrastructure (me neither).
I understand that from an organizational perspective most people like the idea of having the files in the repos, but have technical doubts. Hence, I wonder whether it would be a good idea to take one KDE app to try and showcase this suggestion? Cheers, Julius 20.08.2023 17:55:24 Laura David Hurka <david.hu...@mailbox.org>: > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley wrote: >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore < >> >> scarlett.gately.mo...@gmail.com> wrote: >>> Only on release! We will not be building from master! We don't want >>> unstable snaps. >>> Thanks, >>> Scarlett >> >> In that particular case the jobs should be manually triggered only. >> >> Gitlab CI is really made for building artifacts for a given commit rather >> than for a specified version though, so this is definitely going to be a >> case of things not fitting quite right. >> >> Cheers, >> Ben >> [...] > > This confuses me too. > It seems Scarlett wants to use a “deploy” stage [1] and a job rule [2] > to run snap build&release jobs automatically when the release is done. > > If you mean that Gitlab CI should not be used to automate release jobs, > you should elaborate more how binary-factory is meant to be replaced. > > Otherwise, do you just note that Gitlab CI is suboptimal, > or do you recommend to use something else? > Like: “Release build: automatic is fine. Release publish: please only manual”? > > Cheers, David > > > [1] https://docs.gitlab.com/ee/ci/yaml/#stages > [2] like this: > snap-release-job: > rules: > -if: $CI_COMMIT_TAG =~ /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/ > [...] > see also: > https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefined-cicd-variables-to-run-jobs-only-in-specific-pipeline-types
