Per project repository snapcraft files?

[Ben Cooksley]

On Thu, Aug 24, 2023 at 5:00 AM Albert Astals Cid <aacid at kde.org> wrote:

> El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore va
> escriure:
> > 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.
>
> Honestly I'm still a bit lost on what is you are trying to do regarding
> Snap and the KDE repos :D
>

I have to admit I am similarly confused.

I thought this was originally about CI, which is why I proposed tying this
in through .gitlab-ci.yml.
Using that mechanism if this is really about final release builds doesn't
make much sense.

Having a look at what was committed to Blinken's repository though, i'm not
sure there is much that would stop this being actual CI (assuming someone
got it working within Docker)?


> Are we going for CI or CD?
>
> CI -> snap is compiled on each commit and MR to make sure we don't break
> the snap build
>
> CD -> We have an almost-automated way of doing snap "release" builds.
>
>
> To give some examples:
>
> This is arianna's KDE flatpak CI
>    https://invent.kde.org/graphics/arianna/-/jobs/1142328
>      It builds arianna using flatpak with each commit but the artifacts
> are "unused"
>
>
> This is Okular's KDE Windows CI
>    https://invent.kde.org/graphics/okular/-/jobs/1142178
>      It builds each commit to make sure the Windows build doesn't get
> broken
>
>
> This is Okular's KDE Windows CD
>    https://binary-factory.kde.org/job/Okular_Release_win64/
>      It builds release Okular nightly in a way that is a release build and
> can be easily uploaded to the Windows Store
>
>
> This is Okular flathub CD
>    https://github.com/flathub/org.kde.okular
>    https://buildbot.flathub.org/#/apps/org.kde.okular
>      It is a convenient way to generate new builds each time a stable
> release happens
>
>
> I see you committed this
> https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml
>
>
> What is that going to give us?
>
>
> Cheers,
>   Albert
>

Cheers,
Ben


>
>
> > 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-c
> > > >     icd-variables-to-run-jobs-only-in-specific-pipeline-types
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230824/4650d048/attachment.htm>