action #168400
closedcoordination #58184: [saga][epic][use case] full version control awareness within openQA
coordination #152847: [epic] version control awareness within openQA for test distributions
Improve locking scope of git_clone tasks size:S
Description
Motivation¶
In #164898 we replaced the automatic git fetch cron (fetchneedles) with minion jobs.
There are three possible improvements.
Resolve symlinks before enqueuing¶
Compare the following two minion jobs:
args:
- /var/lib/openqa/share/tests/microos: ~
/var/lib/openqa/share/tests/microos/products/microos/needles: ~
args:
- /var/lib/openqa/share/tests/opensuse: ~
/var/lib/openqa/share/tests/opensuse/products/opensuse/needles: ~
microos
is a symlink to opensuse
. The path resolving happens inside the minion job before getting the lock, but we can avoid creating the job by resolving the symlinks before enqueuing. That way we would profit from the feature to not repeat the same minion job in less than one minute.
Avoid fetch when we can check locally for existing ref DONE¶
For the case when we get a certain git sha in CASEDIR, we currently blindly do a fetch, but we could avoid the fetch and first check locally if the ref is there, which might be likely (for shas only. For branches we must always fetch).
For example our investigation jobs usually specify a sha which is already present.
Avoiding git commands needing network is good.
# pseudo code
if ($ref !~ m/[^a-f0-9]/) {
# sha
git rev-parse --verify $ref
# if it's not there, fetch
}
Reduce scope of minion locks¶
This is more complicated and maybe too much effort for little benefit, but:
In some cases we don't need to call any git commands that could conflict with other commands, e.g. just looking up the remote url.
Or the case mentioned in the previous section would be another command that would not interfere with other git tasks.
Any command that does not change anything.
For those we don't need a lock.
Only at that point where we see we have to do a fetch, we have to get the lock.
This reduces the chances of other tasks having to retry because it couldn't get a lock.
It's just problematic because if a task has two paths to update, and you only realize for the second one that you need the lock, you would have to retry, but you don't want to repeat the commands for the first path.
The notes
field could act as a kind of state which of the paths have already been done.
Acceptance criteria¶
- AC1: Minion locks used for Git tasks take symlinking of case/needle directories into account.