Per project repository snapcraft files?

[Scarlett Moore]

On Sat, Aug 19, 2023, 1:31 AM Ben Cooksley <bcooksley at kde.org> wrote:

> 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?
>

We won't because as it currently works is we do a public upload to
launchpad which places us at the bottom of the priority list, hence
timeouts and other random failures. This way we can build proper snap
recipes on launchpad and have a high priority. This was suggested to me by
the launchpad team as public uploads are just a temporary recipe and cannot
have priority changed. Thank you very much for all your help, I will start
this next week unless otherwise told.
Thank you!
Scarlett

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