duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 21.03.2022 22:05, Aaron wrote:
> On 2022-03-21 20:50, Aaron wrote:
>
> > I feel like the "proper" solution here is to add a step to the CI/CD process on Gitlab to test the snap before it goes to stable. That is a bit awkward as snaps do not run inside Docker containers, which are what is easiest in Gitlab CI/CD. I will try to make some time to investigate this -- maybe I can set up a spend-limited Linode API key and just have it run some smoke tests on the snap as part of a specified release process or something. To do it all as a pipeline, I think we would have to do the release and snapping in there as well.
> As much to help me find it again in the future, I see that I found some guidance on building snaps on Gitlab and pushing them to the snap store here:

how about we move this discussion into a ticket on gitlab, so it get's archived for the future? :)

> https://forum.snapcraft.io/t/building-and-pushing-snap-packages-from-gitlab/9537 <https://forum.snapcraft.io/t/building-and-pushing-snap-packages-from-gitlab/9537>
>
> It's a bit old now, but hopefully still useful. Perhaps we can now use remote build to avoid faffing with special containers for building?

having done some remote building, i'd say f***ing slow but very useful for non amd64 archs. having said that. snapping locally in a CI will probably still be the fastest, although personally i do build and push releases manually, always, just to keep things under control. it's not like i release daily or so ;)

..ede