QA » openQA Project

I feel like it's fair to say we didn't get to this at the workshop. Let's estimate it tomorrow.

I feel like this might not be picked over other High tickets atm because it's a new feature? Maybe it should have lower priority? I'm asking in the team chat once more.

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/187 was just merged. Not sure what this is about.

I did the following experiment:

• I clone a openqa-to-openqa job with git url in CASEDIR+NEEDLES_DIR. tests pulled the repos in /var/lib/openqa/share/tests/openqa and run successfully
• created a PR https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/187 and merged.
• then I restarted the cloned job in my local setup and it run against the new changes. However change was not in /var/lib/openqa/share/tests/openqa

livdywan wrote in #note-12:

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/187 was just merged. Not sure what this is about.

I have to revert it.

ybonatakis wrote in #note-14:

livdywan wrote in #note-12:

https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/187 was just merged. Not sure what this is about.

I have to revert it.

Actually someone already did it https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/188

It looks like we can just use the OpenQA::Task::Git::Clone minion job for this as well, with some changes.
https://github.com/os-autoinst/openQA/commit/a38165bd7576d7ebba5497478636e176fb83daa1
I made some minor adjustments, so that instead of passing

/path/to/share/tests/foo: git-url
/path/to/share/tests/foo/needles: git-url

you can leave the values empty (when no CASEDIR / NEEDLES_DIR is set):

/path/to/share/tests/foo: null
/path/to/share/tests/foo/needles: null

and then it will only do a git fetch etc. if the clone already exists in the given path.

One thing to consider: If people are working with a git repo directly in /path/to/share/tests/foo (or a symlink to their clone), then the minion job should probably not do anything in there. Most commands are harmless, except the git reset --hard.
Question is, how to find out if the git clone is really just a clone or the actual developer git. Checking for a dirty status might not be enough.

https://github.com/os-autoinst/openQA/pull/5808 Proof of Concept: Support git_auto_clone for empty CASDIR/NEEDLES_DIR

To test:

openqa.ini:

[scm git]
git_auto_clone = yes

Clone https://github.com/os-autoinst/os-autoinst-distri-openQA into /path/to/openqa/share/tests/openqa.
Start openqa daemons including gru.
Then run

openqa-clone-job --host http://localhost:9526 https://openqa.opensuse.org/tests/4360561 _TRIGGER_JOB_DONE_HOOK=0 SCHEDULE=tests/install/boot CASEDIR=

In the gru log you should see all executed git commands.

• Editing a file in the checkout results in the minion job not updating the repo because of a dirty status
• An empty CASEDIR/NEEDLES_DIR will auto clone, but explicitly specifying a local path will not

Todos

• Conflicts because of save_needle need to be handled
• Related: We regularly have problems with the index file when running save_needle: https://openqa.opensuse.org/minion/jobs?task=save_needle&state=&queue=¬e=

% git status
fatal: .git/index: index file smaller than expected

• save_needle code should be reviewed. Maybe code can be reused. OpenQA::Task::Needle::Save uses OpenQA::Git, OpenQA::Task::Git::Clone doesn't
• How to prevent updating a user's working git clone?

Since we currently haven't git_auto_clone enabled on o3/osd, we can roll out the feature and enable it and can monitor.
Important: fetchneedles needs to be disabled then.

We could already add the git gc and git diff-index to the current code.