Per project repository snapcraft files?

[Nicolas Fella]

Am 18.08.23 um 21:41 schrieb Ben Cooksley:
> On Fri, Aug 18, 2023 at 10:17 PM Scarlett Moore
> <scarlett.gately.moore at gmail.com> wrote:
>
>
>
>     On Fri, Aug 18, 2023, 12:55 AM Ben Cooksley <bcooksley at kde.org> wrote:
>
>         On Fri, Aug 18, 2023 at 3:53 AM Scarlett Moore
>         <scarlett.gately.moore at gmail.com> wrote:
>
>             Hello everyone,
>
>
>         Hey Scarlett,
>
>             I am asking to revisit per project repo snapcraft files. I
>             see now
>             that flatpak files are in project repos but I understand
>             this was
>             rejected for snapcraft. I would like to re-propose the
>             idea, and here
>             is why.
>             The CI jobs for snap builds is cludgy at best. We have
>             huge amounts of
>             failures because we must do a public upload to launchpad
>             which places
>             us at the lowest priority and we have many timeouts etc. Their
>             solution is to create proper snap recipes pointing to our
>             repos with
>             the snapcraft.yaml. Our current setup won't work because
>             we use
>             subdirectories in one repo.
>             Thoughts?
>
>
>         My understanding (when automating the triggering of these
>         builds on invent.kde.org <http://invent.kde.org> was discussed
>         with Sysadmin) was that the Snap folks had wanted to have
>         everything in one repository.
>         I had queried at the time why we weren't adding a file into
>         each repository (which is what we do with Flatpak, and now
>         with Craft as well - although those builds have yet to be
>         widely rolled out)
>
>         With regards to the triggering of these builds, how will this
>         happen?
>         It sounds like what you are describing here will result in
>         Canonical servers polling invent.kde.org
>         <http://invent.kde.org> for changes, which is something we're
>         not huge fans of as most projects only change every couple of
>         days.
>
>
>             Thanks for your time,
>             Scarlett
>
>
>         Cheers,
>         Ben
>
>
>
>     Hi!
>
>     Thanks all for responding.
>
>     Albert: snapcraft files have been ironed out. I have been quite
>     busy over the last year doing so.
>
>     Ben: There is an option to have launchpad build on changes which
>     would have polling. However, I would opt out of this feature and
>     instead write some tooling using launchpad API and Neons watcher
>     tooling to update versions and trigger launchpad builds. It would
>     actually lighten the load on KDE servers significantly.
>
>
> Yes, we would definitely want to opt out of that completely - due to
> the number of repositories we have, any kind of polling quickly turns
> into a fairly significant number of requests.
>
> Wouldn't you want to trigger this from a .gitlab-ci.yml job definition
> though like we do for Flatpak and will be doing very soon for all of
> the Craft builds that support Android, Windows and Linux appimage
> binaries?
I was about to ask how the "future binary-factory" on invent will look
like and suggest to follow that precedent. Can you elaborate on that?
Will these be jobs in the relevant repos or will there be a meta-repo
with all of the "release" jobs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230818/15b0bf70/attachment.htm>