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 <aa...@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 <aa...@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.zo...@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.kde...@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.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-predefin > > > > > > ed-c > > > > > > icd-variables-to-run-jobs-only-in-specific-pipeline-types > > > > >
