Hello, I guess that this email thread is about "Can we please add the file ".snapcraft.yaml" to KDE git repositories.
I could build https://invent.kde.org/education/blinken as a snap file, install the snap file and run blinken correctly. Thanks. Details/steps: I use Kubuntu 23.04, as per https://snapcraft.io/docs/snapcraft-overview, I did: sudo snap install snapcraft --classic # (it installs snaps for snapcraft) mkdir ~/firstsnap snapcraft init Restart the computer such that the command "groups" will return "lxd". git clone https://invent.kde.org/education/blinken.git or kdesrc-build blinken cd /home/nmariusp/kde5/src/blinken/ snapcraft --debug sudo snap install blinken_23.08.0_amd64.snap --devmode blinken # ($PATH environment variable ends in "/snap/bin") On Thu, Aug 24, 2023 at 1:33 PM Ben Cooksley <bcooks...@kde.org> wrote: > On Thu, Aug 24, 2023 at 5: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 >> > > 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.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-predefined-c >> > > > icd-variables-to-run-jobs-only-in-specific-pipeline-types >> >> >> >> >>
