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
