Per project repository snapcraft files?
Scarlett Moore
scarlett.gately.moore at gmail.com
Thu Aug 24 02:04:53 BST 2023
I believe snaps has a similar github build setup as well. I will look into
it. This completely defeats the whole purpose in which I wanted this in the
first place though. Developers getting involved and helping with their
snaps. Alas I digress.
Scarlett
On Wed, Aug 23, 2023, 3:27 PM Albert Astals Cid <aacid at kde.org> wrote:
> El dimecres, 23 d’agost de 2023, a les 19:13:46 (CEST), Scarlett Moore va
> escriure:
> > On Wed, Aug 23, 2023 at 10: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
> > The same as flatpak, minus the daily builds.
>
> I don't see the similarities with what we have in KDE-flatpak land
>
> For KDE-flatpak we have:
> * CI, which you say this is not about CI
> * CD on flathub, which uses the released tarballs instead of git, and the
> description file is in github and not on invent
> * CD on binary factory, this one is based on git, but that's just master/
> nightlies no one is suppose to use
>
> >
> > > 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.
> >
> > CD via launchpad.
>
> Were can i check the status of a given app?
>
> i.e. the counterpart of https://buildbot.flathub.org/#/apps/org.kde.okular
>
> >
> > > 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"
> > We could set set that up but I find it unnecessary. Launchpad can
> > build and upload to edge channel.
> >
> > > 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
> > This will be the same, but with launchpad.
> >
> > > I see you committed this
> > > https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml
> > >
> > >
> > > What is that going to give us?
> >
> > Snaps. In this case launchpad will build master and upload to edge
> channel.
> > I also commited to the stable branch in which launchpad will build and
> > upload to the candidate/stable channel.
>
> You're building stable snaps from git branch instead of tarballs, right?
>
> Does this mean a new snap is built [and distributed to the users?] for
> each
> commit we make to the stable branch?
>
>
>
> Cheers,
> Albert
>
> >
> > > Cheers,
> > >
> > > Albert
> >
> > Thanks,
> > Scarlett
> >
> > > > 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-predefin
> > > > > > ed-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/20230823/9d9dd5a6/attachment-0001.htm>
More information about the kde-devel
mailing list