<div dir="auto"><div>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.</div><div dir="auto">Scarlett<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Aug 23, 2023, 3:27 PM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank" rel="noreferrer">aacid@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El dimecres, 23 d’agost de 2023, a les 19:13:46 (CEST), Scarlett Moore va <br>
escriure:<br>
> On Wed, Aug 23, 2023 at 10:00 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" rel="noreferrer noreferrer" target="_blank">aacid@kde.org</a>> wrote:<br>
> > El dimecres, 23 d’agost de 2023, a les 18:29:10 (CEST), Scarlett Moore va <br>
escriure:<br>
> > > After some testing and various complicated options, the easiest I have<br>
> > > found is importing our github mirror in launchpad ( this avoids the<br>
> > > polling on kde servers ) and we can create our necessary snap recipes<br>
> > > and KDE infrastructure is unaffected save the already in place github<br>
> > > mirror. Launchpad does everything else ( building and uploading to<br>
> > > store ) I see no reason not to move forward as KDE infrastructure will<br>
> > > have much less involvement in the snap lifecycle aside from the<br>
> > > snapcraft files being in the application repository. As mentioned<br>
> > > before this will allow developers closer involvement with snap<br>
> > > developers.<br>
> > <br>
> > Honestly I'm still a bit lost on what is you are trying to do regarding<br>
> > Snap and the KDE repos :D<br>
> The same as flatpak, minus the daily builds.<br>
<br>
I don't see the similarities with what we have in KDE-flatpak land<br>
<br>
For KDE-flatpak we have:<br>
* CI, which you say this is not about CI<br>
* CD on flathub, which uses the released tarballs instead of git, and the <br>
description file is in github and not on invent<br>
* CD on binary factory, this one is based on git, but that's just master/<br>
nightlies no one is suppose to use<br>
<br>
> <br>
> > Are we going for CI or CD?<br>
> > <br>
> > CI -> snap is compiled on each commit and MR to make sure we don't break<br>
> > the snap build<br>
> > <br>
> > CD -> We have an almost-automated way of doing snap "release" builds.<br>
> <br>
> CD via launchpad.<br>
<br>
Were can i check the status of a given app?<br>
<br>
i.e. the counterpart of <a href="https://buildbot.flathub.org/#/apps/org.kde.okular" rel="noreferrer noreferrer noreferrer" target="_blank">https://buildbot.flathub.org/#/apps/org.kde.okular</a><br>
<br>
> <br>
> > To give some examples:<br>
> > <br>
> > This is arianna's KDE flatpak CI<br>
> > <br>
> > <a href="https://invent.kde.org/graphics/arianna/-/jobs/1142328" rel="noreferrer noreferrer noreferrer" target="_blank">https://invent.kde.org/graphics/arianna/-/jobs/1142328</a><br>
> > <br>
> > It builds arianna using flatpak with each commit but the artifacts<br>
> > are "unused"<br>
> We could set set that up but I find it unnecessary. Launchpad can<br>
> build and upload to edge channel.<br>
> <br>
> > This is Okular's KDE Windows CI<br>
> > <br>
> > <a href="https://invent.kde.org/graphics/okular/-/jobs/1142178" rel="noreferrer noreferrer noreferrer" target="_blank">https://invent.kde.org/graphics/okular/-/jobs/1142178</a><br>
> > <br>
> > It builds each commit to make sure the Windows build doesn't get<br>
> > broken<br>
> > <br>
> > This is Okular's KDE Windows CD<br>
> > <br>
> > <a href="https://binary-factory.kde.org/job/Okular_Release_win64/" rel="noreferrer noreferrer noreferrer" target="_blank">https://binary-factory.kde.org/job/Okular_Release_win64/</a><br>
> > <br>
> > It builds release Okular nightly in a way that is a release build and<br>
> > can be easily uploaded to the Windows Store> <br>
> > This is Okular flathub CD<br>
> > <br>
> > <a href="https://github.com/flathub/org.kde.okular" rel="noreferrer noreferrer noreferrer" target="_blank">https://github.com/flathub/org.kde.okular</a><br>
> > <a href="https://buildbot.flathub.org/#/apps/org.kde.okular" rel="noreferrer noreferrer noreferrer" target="_blank">https://buildbot.flathub.org/#/apps/org.kde.okular</a><br>
> > <br>
> > It is a convenient way to generate new builds each time a stable<br>
> > release happens<br>
> This will be the same, but with launchpad.<br>
> <br>
> > I see you committed this<br>
> > <a href="https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml" rel="noreferrer noreferrer noreferrer" target="_blank">https://invent.kde.org/education/blinken/-/blob/master/.snapcraft.yaml</a><br>
> > <br>
> > <br>
> > What is that going to give us?<br>
> <br>
> Snaps. In this case launchpad will build master and upload to edge channel.<br>
> I also commited to the stable branch in which launchpad will build and<br>
> upload to the candidate/stable channel.<br>
<br>
You're building stable snaps from git branch instead of tarballs, right? <br>
<br>
Does this mean a new snap is built [and distributed to the users?] for each <br>
commit we make to the stable branch?<br>
<br><br><br>
Cheers,<br>
Albert<br>
<br>
> <br>
> > Cheers,<br>
> > <br>
> > Albert<br>
> <br>
> Thanks,<br>
> Scarlett<br>
> <br>
> > > Thanks,<br>
> > > Scarlett<br>
> > > <br>
> > > On Sun, Aug 20, 2023 at 7:20 PM Justin Zobel <<a href="mailto:justin.zobel@gmail.com" rel="noreferrer noreferrer" target="_blank">justin.zobel@gmail.com</a>> <br>
wrote:<br>
> > > > I think there is a lot of misunderstanding here.<br>
> > > > <br>
> > > > In GitLab CI only test builds are done and artifacts are kept so<br>
> > > > people<br>
> > > > can test an AppImage or Flatpak without having to compile locally.<br>
> > > > <br>
> > > > Stable releases are done by the Release Team via scripts to tarballs.<br>
> > > > Flatpaks are done via Flathub and are done (usually) automatically via<br>
> > > > the Flatpak External Data Checker.<br>
> > > > <br>
> > > > Hopefully this clarifies the situation.<br>
> > > > <br>
> > > > On 21/8/23 08:48, Scarlett Moore wrote:<br>
> > > > > On Sun, Aug 20, 2023, 4:14 PM Julius Künzel<br>
> > > > > <br>
> > > > > <<a href="mailto:jk.kdedev@smartlab.uber.space" rel="noreferrer noreferrer" target="_blank">jk.kdedev@smartlab.uber.space</a>> wrote:<br>
> > > > > To me it seems this discussion is quite abstract and there are<br>
> > > > > several misunderstandings because not everybody knows every<br>
> > > > > detail<br>
> > > > > of snap packaging and/or the KDE infrastructure (me neither).<br>
> > > > > <br>
> > > > > I understand that from an organizational perspective most people<br>
> > > > > like the idea of having the files in the repos, but have<br>
> > > > > technical<br>
> > > > > doubts. Hence, I wonder whether it would be a good idea to take<br>
> > > > > one KDE app to try and showcase this suggestion?<br>
> > > > > <br>
> > > > > Cheers,<br>
> > > > > Julius<br>
> > > > > <br>
> > > > > Sounds like a great idea to me.<br>
> > > > > Scarlett<br>
> > > > > <br>
> > > > > 20.08.2023 17:55:24 Laura David Hurka <<a href="mailto:david.hurka@mailbox.org" rel="noreferrer noreferrer" target="_blank">david.hurka@mailbox.org</a>>:<br>
> > > > > > On Sunday, August 20, 2023 12:47:10 PM CEST Ben Cooksley <br>
wrote:<br>
> > > > > >> On Sun, Aug 20, 2023 at 12:43 PM Scarlett Moore <<br>
> > > > > >> <br>
> > > > > >> <a href="mailto:scarlett.gately.moore@gmail.com" rel="noreferrer noreferrer" target="_blank">scarlett.gately.moore@gmail.com</a>> wrote:<br>
> > > > > >>> Only on release! We will not be building from master! We<br>
> > > > > >>> don't<br>
> > > > > <br>
> > > > > want<br>
> > > > > <br>
> > > > > >>> unstable snaps.<br>
> > > > > >>> Thanks,<br>
> > > > > >>> Scarlett<br>
> > > > > >> <br>
> > > > > >> In that particular case the jobs should be manually triggered<br>
> > > > > >> only.<br>
> > > > > >> <br>
> > > > > >> Gitlab CI is really made for building artifacts for a given<br>
> > > > > <br>
> > > > > commit rather<br>
> > > > > <br>
> > > > > >> than for a specified version though, so this is definitely<br>
> > > > > <br>
> > > > > going to be a<br>
> > > > > <br>
> > > > > >> case of things not fitting quite right.<br>
> > > > > >> <br>
> > > > > >> Cheers,<br>
> > > > > >> Ben<br>
> > > > > >> [...]<br>
> > > > > > <br>
> > > > > > This confuses me too.<br>
> > > > > > It seems Scarlett wants to use a “deploy” stage [1] and a job<br>
> > > > > <br>
> > > > > rule [2]<br>
> > > > > <br>
> > > > > > to run snap build&release jobs automatically when the release<br>
> > > > > > is<br>
> > > > > <br>
> > > > > done.<br>
> > > > > <br>
> > > > > > If you mean that Gitlab CI should not be used to automate<br>
> > > > > <br>
> > > > > release jobs,<br>
> > > > > <br>
> > > > > > you should elaborate more how binary-factory is meant to be<br>
> > > > > <br>
> > > > > replaced.<br>
> > > > > <br>
> > > > > > Otherwise, do you just note that Gitlab CI is suboptimal,<br>
> > > > > > or do you recommend to use something else?<br>
> > > > > > Like: “Release build: automatic is fine. Release publish:<br>
> > > > > > please<br>
> > > > > <br>
> > > > > only manual”?<br>
> > > > > <br>
> > > > > > Cheers, David<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > [1] <a href="https://docs.gitlab.com/ee/ci/yaml/#stages" rel="noreferrer noreferrer noreferrer" target="_blank">https://docs.gitlab.com/ee/ci/yaml/#stages</a><br>
> > > > > > [2] like this:<br>
> > > > > > <br>
> > > > > > snap-release-job:<br>
> > > > > > rules:<br>
> > > > > > -if: $CI_COMMIT_TAG =~<br>
> > > > > > /^v[0-9][0-9]\.[0-9][0-9]\.[0-9][0-9]$/<br>
> > > > > > <br>
> > > > > > [...]<br>
> > > > > > <br>
> > > > > > see also:<br>
> > > > > <a href="https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefin" rel="noreferrer noreferrer noreferrer" target="_blank">https://docs.gitlab.com/ee/ci/jobs/job_control.html#use-predefin</a><br>
> > > > > ed-c<br>
> > > > > icd-variables-to-run-jobs-only-in-specific-pipeline-types<br>
<br>
<br>
<br>
<br>
</blockquote></div></div></div>