Per project repository snapcraft files?
Marius P
nmariusp1 at gmail.com
Thu Aug 24 13:47:13 BST 2023
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 <bcooksley at kde.org> wrote:
> On Thu, Aug 24, 2023 at 5: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
>>
>
> 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.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-predefined-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/20230824/bea33eb4/attachment.htm>
More information about the kde-devel
mailing list