[ https://ovirt-jira.atlassian.net/browse/OVIRT-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35718#comment-35718 ]
{quote} Looks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. {quote}
We use pipelines – Jenkinfiles are pipeline-based but also impose a very specific workflow, while generic pipelines are far more flexible.
{quote} With the Jenkinsfile the chroot based approach seems to be pretty obsolete, {quote}
Nope,there are quite a few things the current approach makes easy to do that Jenkinsfile would make complex or impossible. The main point of the current approach is not the use of mock/chroot, which is an implementation detail, but the use of a standardized generic configuration format, where different backends could be implemented.
It allows the CI team to deal effectively with how CI resources are distributed and managed while allowing developers to just specify what they need. With Jenkinsfile the developers would have to deal with a lot of the mechanics or resource allocation and management, while the CI team will be unable to control how resources are used or to ensure they are returned to usable state when jobs finish.
The configuration formal also allows the CI system to gain a good knowledge about the dependencies for a given test/build process. This allows it to to control how and which versions of these dependencies are provided. (For example, when you ask for yum repositories, the CI system ensure you get the same view of these repositories from the point in time in which the jobs started, even if they get updated while the job is running).
Jenkinsfile, as it stands, will also chain us to a very specific CI orchestration engine. Don't get me wrong, Jenkins is nice, but its good to know we can switch the backend and have that switch be mostly transparent to project developers. Its also very convenient to have a client-side mini-backend, it would be quite impossible to make such a backend for a Jenkinsfile.
{quote} if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable. {quote}
STDCI have been quite valuable so far TYVM.
Using the docker agent as you suggest will actually make it lees so because it will chain you to a very specific method of resource allocation. It will make it harder to do things like ensure a certain test script gets its own bare-metal machine to run on.
Docker containers are useful – but many people couldn't care less, they just know they need to target ‘el7’ and need a few dependencies for that, forcing then to then deal with finding or making a suitable container image will just divert efforts from the more important work of writing the actual code to be tested.
The main thing that Jenkinsfiles have to offer that STDCI does not support currently is the ability to sequentially chain multiple steps together and have control flow to decide which steps get executed. We are going to make STDCI provide that, and we're going to try to do that in a syntax that would be familiar to anyone who is familiar with Jenkinsfiles. But it is going to be a subset of the Jenkinsfie syntax. Things like node() for example, are probably not going to be supported since STDCI already provides higher-level ways of requesting node allocation.
Allow engineers to write Jenkinsfiles
Key: OVIRT-1868 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1868 Project: oVirt - virtualization made easy Issue Type: By-EMAIL Reporter: Roman Mohr Assignee: infraLooks like standard-ci switched internally to use Jenkinsfiles. However it would be very valuable for engineers, if they could just write their Jenkinsfile, instead of all the usual standard-ci yamls/scripts. With the Jenkinsfile the chroot based approach seems to be pretty obsolete, if you allow people to use the docker agent for the Jenkinsfile. For KubeVirt it would make standard-ci finally really valuable.
— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)