Per project repository snapcraft files?

[Scarlett Moore]

After some testing and various complicated options, the easiest I have
found is importing our github mirror in launchpad ( this avoids the
polling on kde servers ) and we can create our necessary snap recipes
and KDE infrastructure is unaffected save the already in place github
mirror. Launchpad does everything else ( building and uploading to
store ) I see no reason not to move forward as KDE infrastructure will
have much less involvement in the snap lifecycle aside from the
snapcraft files being in the application repository. As mentioned
before this will allow developers closer involvement with snap
developers.
Thanks,
Scarlett

On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel <justin.zobel at gmail.com> wrote:
>
> I think there is a lot of misunderstanding here.
>
> In GitLab CI only test builds are done and artifacts are kept so people
> can test an AppImage or Flatpak without having to compile locally.
>
> Stable releases are done by the Release Team via scripts to tarballs.
> Flatpaks are done via Flathub and are done (usually) automatically via
> the Flatpak External Data Checker.
>
> Hopefully this clarifies the situation.
>
> On 21/8/23 08:48, Scarlett Moore wrote:
> >
> >
> > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel
> > <jk.kdedev at smartlab.uber.space> wrote:
> >
> >     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
> >
> > Sounds like a great idea to me.
> > Scarlett
> >
> >
> >
> >
> >     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
> >