Per project repository snapcraft files?

[Julius Künzel]

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.hurka at 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.moore at 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