Kenneth and team,
On Mon, Jan 13, 2020 at 5:50 AM Aaron <lists@xxxxxxxxxxxxxxxxxx <mailto: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:
1. Reserve Edge for bleeding edge like automatically created snaps from Master.
2. You (Kenneth) put new releases into Beta.
3. 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.
4. 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.
5. 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 <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 <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
_______________________________________________
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
