Per project repository snapcraft files?

[Scarlett Moore]

On Fri, Aug 18, 2023, 12:53 PM Ben Cooksley <bcooksley at kde.org> wrote:

> On Sat, Aug 19, 2023 at 7:45 AM Nicolas Fella <nicolas.fella at gmx.de>
> wrote:
>
>> 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 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 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 am definitely game for following a standard and do what everyone else
is doing. Just point me to instructions and I will do it.
Thanks!
Scarlett

> 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?
>>
>
> The jobs will be sitting in the relevant repositories in a separate stage
> to the current CI.
> There will not be a meta repo for this.
>
> Individual applications for Craft will configure any extra behaviour they
> need via a .craft.ini file at top level in the repository, on the branch in
> question that the behaviour change is needed.
> This is keeping in line with how our CI works (with .kde-ci.yml) and the
> Flatpak builds work (with .flatpak-manifest.json/yml).
>
> Yet to be fully worked out how the triggering of them will be setup,
> whether it will be automatic or whether it will be manually run but that is
> an implementation detail.
>
> Cheers,
> Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230818/71d804d4/attachment.htm>