duplicity-team team mailing list archive

[Aaron <lists@xxxxxxxxxxxxxxxxxx>]

Kenneth and team,

On Mon, Jan 13, 2020 at 5:50 AM Aaron <lists@xxxxxxxxxxxxxxxxxx> wrote:

> [...]
>
> If it would be helpful, I would be happy to volunteer to be more 
> involved in the testing and release process of snaps through channels 
> to give a second pair of eyes/small amount more QA.
>
> We could do something with the snap channels like the following:
>
> * Reserve Edge for bleeding edge like automatically created snaps from 
> Master.
> * You (Kenneth) put new releases into Beta.
> * I could run some basic tests (I have the beginnings of some scripts 
> that run tests in bare lxc containers to catch missing undeclared 
> dependencies etc) and, if all looks good, promote them from Beta into 
> Candidate.
> * We could leave these sitting in Candidate for at least a week or so. 
> If I know these have had some initial tests then I'm happy to switch 
> some of my boxes to this track. Hopefully others on the team will, too. 
> Then we will catch any major issues (like this) before any Stable 
> users.
> * When/If you think appropriate, you can advance any candidates to 
> Stable.
>
> Up to you, of course. My intention is to keep you in control of both 
> adding new snaps and releasing to stable, but giving one additional set 
> of checks/pair of eyes before hitting anyone's production boxes. I 
> think Snaps are a great distribution mechanism for us, but it does mean 
> there's no distro testing/QA/beta process between us and our users and 
> we need to take a bit more of that responsibility.

[...]

On 2020-01-13 17:23, Kenneth Loafman wrote:

> Aaron,
>
> I agree with everything you said!
>
> I'll start pushing to _candidate_ instead of _stable_ for releases. You 
> can check it out and promote it to stable.  Snaps may lag behind repo 
> releases, but that's OK.  One change I've made is that now snaps are 
> versioned with the revno of the repo, like 0.8.10rev1548 so we can 
> identify them better.
>
> > [...]

I am resurrecting this old thread because it looks to me as though the 
stable snap broke again 
(https://gitlab.com/duplicity/duplicity/-/issues/119 -- it also broke 
for me, looks like the last two days and also back on 8 and 9 March, so 
I suspect rev 243 and 250). I would like to try to do more to help solve 
this problem, so I am not criticising -- I know you have asked for help 
and I have not offered to do any more and you have been left carrying 
all the work.

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.

A while back you summarised your build/release process for the list 
here:

https://lists.launchpad.net/duplicity-team/msg04839.html

Would you mind please setting out what you do now, including the 
snapping part? I see there is a makesnap, testsnap and pushsnap in the 
tools folder, for example.

I actually have my main server tracking Release Candidate instead of 
Stable as mentioned above, so I likely would have caught this latest 
issue before it went to stable if it went into candidate for even a few 
days before stable. Perhaps, therefore, until we have something where 
the snap is tested automatically, we could go for a putting the snaps in 
the candidate channel, you could post to this list and I (or someone 
else) can do a quick test and give you a +1 before bumping it into 
stable? I believe most of the issues we have seen with snaps mean they 
are completely broken and not even a duplicity --version works, so the 
testing burden should be pretty low. As I say, I have my server on 
candidate and it sends me an email if my daily backup job fails, so I 
should notice it pretty quickly if there is a broken snap in candidate 
even if I miss your email.

Many thanks again Kenneth for all of your work.

Aaron