Per project repository snapcraft files?

[Ben Cooksley]

On Sat, Aug 19, 2023 at 8:47 AM Scarlett Moore <
scarlett.gately.moore at gmail.com> wrote:

>
>
> 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
>
>>
>>>
[Trim]

Like many things, there are no written instructions as it were, however
there are quite a few examples of how the other jobs are doing it.
See
https://invent.kde.org/sysadmin/ci-utilities/-/tree/master/gitlab-templates
for the existing templates we have for this.

You'll see in the case of Flatpak and co that we're always referring to the
sources in the current branch - ideally you will be able to do this with
Snap as well.

Only thing i'm confused about here is how having the file in the actual
repo makes a difference from Canonical's end as you'll still be getting
their systems to trigger the builds and presumably still getting the same
set of failures?

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20230819/eb462a2a/attachment-0001.htm>