Project

General

Profile

action #168400

Updated by tinita 23 days ago

## 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](https://github.com/os-autoinst/openQA/pull/6017)* 

 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.

Back