I think that it can be hard for %9.3 specifically, before the merge window close. I would expect more to happen in this quiet period after merge window close and before we start work on %9.4.
@rspeicher@rymai Implementing a test example for backup / restore might need some additional work in GitLab QA. It should not be very difficult, but this is also not easy.
This is how I see it:
This test should be added to qa/ directory in CE / EE repository, because gitlab-ctl command is implemented there.
We still need to trigger this test from a GitLab QA, as usual.
qa/ directory contains instance specs, we can trigger that using Test::Instance http://example.com scenario, but we should have a separate endpoint for administration tests.
Maybe we should add Test::Maintenance or Test::Shell scenario.
We would need to either resolve #40 (closed), to make it possible to call docker exec from within the instance specs container, or use SSH to invoke gitlab-ctl. I think that former solution makes more sense, since we need DinD approach anyway, and it will be much easier to implement docker exec than SSH access.
Test scenario on a GitLab QA side should be something like:
Run instance tests to populate database with data
Run backup store scenario
[optional] restart container to clear database data?
@rymai I think that we already have feature tests for backup store / restore, so I think the OKR is about the GitLab QA.
That said, I recently prepared everything what we needed to test backup store / restore, it should be easy to implement that now. I was planning to do that on my own, but if ~Platform team wants to take a stab on that, I will be glad to hand it over to someone else /cc @DouweM
@grzesiek I don't know yet if we're going to have time to do it, since the team has lost a few people to Geo since those OKRs were written up. If you have time work finish it yourself, that'd be great, but if not, feel free to create a WIP MR with what you have so far, and someone from ~Platform may just take it over!
I'm not working on it right now, but I plan to do it after shipping some other improvements to GitLab QA. I'm going to unassign myself from this issue for the time being.