standard CI packages files
Hi all, The various automation/*.packages* files are rather hard to maintain - with many partial duplicates, symlinks, and changes applied to some file forgotten to be applied to others that needed them. Can we have something more dynamic? E.g. that CI will run a single script, e.g. automation/get-needed-packages, provide it as args the action to be ran ("check-patch", "build-artifacts" etc.) and the distro ("el7", "fc27" etc.) and use whatever it outputs as the list of packages to install? Thanks, -- Didi
On 12 March 2018 at 09:55, Yedidyah Bar David <didi@redhat.com> wrote:
Hi all,
The various automation/*.packages* files are rather hard to maintain - with many partial duplicates, symlinks, and changes applied to some file forgotten to be applied to others that needed them.
Can we have something more dynamic? E.g. that CI will run a single script, e.g. automation/get-needed-packages, provide it as args the action to be ran ("check-patch", "build-artifacts" etc.) and the distro ("el7", "fc27" etc.) and use whatever it outputs as the list of packages to install?
The problem with this approach is that its a slippery slope - because the script to calculate the packages might need packages of its own to run... In STDCI V2 we laid the groundwork for using a single YAML file to specify everything, this will open up the possibility of using YAML inheritance and macros to share specification parts between different jobs. I think that can be a good enough compromise. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Mon, Mar 12, 2018 at 10:42 AM, Barak Korren <bkorren@redhat.com> wrote:
On 12 March 2018 at 09:55, Yedidyah Bar David <didi@redhat.com> wrote:
Hi all,
The various automation/*.packages* files are rather hard to maintain - with many partial duplicates, symlinks, and changes applied to some file forgotten to be applied to others that needed them.
Can we have something more dynamic? E.g. that CI will run a single script, e.g. automation/get-needed-packages, provide it as args the action to be ran ("check-patch", "build-artifacts" etc.) and the distro ("el7", "fc27" etc.) and use whatever it outputs as the list of packages to install?
The problem with this approach is that its a slippery slope - because the script to calculate the packages might need packages of its own to run...
I see your point, but not sure it's a real problem.
In STDCI V2 we laid the groundwork for using a single YAML file to specify everything, this will open up the possibility of using YAML inheritance and macros to share specification parts between different jobs. I think that can be a good enough compromise.
Perhaps. When will we have this? Thanks, -- Didi
On 12 March 2018 at 10:48, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Mar 12, 2018 at 10:42 AM, Barak Korren <bkorren@redhat.com> wrote:
On 12 March 2018 at 09:55, Yedidyah Bar David <didi@redhat.com> wrote:
Hi all,
The various automation/*.packages* files are rather hard to maintain - with many partial duplicates, symlinks, and changes applied to some file forgotten to be applied to others that needed them.
Can we have something more dynamic? E.g. that CI will run a single script, e.g. automation/get-needed-packages, provide it as args the action to be ran ("check-patch", "build-artifacts" etc.) and the distro ("el7", "fc27" etc.) and use whatever it outputs as the list of packages to install?
The problem with this approach is that its a slippery slope - because the script to calculate the packages might need packages of its own to run...
I see your point, but not sure it's a real problem.
In STDCI V2 we laid the groundwork for using a single YAML file to specify everything, this will open up the possibility of using YAML inheritance and macros to share specification parts between different jobs. I think that can be a good enough compromise.
Perhaps. When will we have this?
We can migrate your project to V2 today (We're looking for early adopters ATM), but current feature set does not include the in-lining of package, repo, etc. definitions into YAML. We'll need to rewrite mock_runner.sh for that (Or write <something-else>_runner.sh...) so no definite deadline for that (This is why I wrote 'laid the groundwork' as opposed to 'implemented'). The existing V2 feature-set can be useful though - the main thing is that the definitions of the platforms, archs and oVirt versions you target moves out of the 'jenkins' repo and into your own. There are also some other useful things such are the ability to arbitrarily name the scripts used and the ability to run multiple scripts in parallel. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
participants (2)
-
Barak Korren -
Yedidyah Bar David