Toward self-configuring CI, or how can we stop writing YAML
Hi all, The premise of the CI standard is simple: You (the developers) place simple script in the 'automation' directory, and we (the infa team) take care of making Jenkins run it when it should. But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc. The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases. We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. Here are my ideas on how to do that: We already have a way to specify platforms in the 'automation' directory: scripts and files in the 'automation' directory can be suffixed with a platform name, this make them apply only to that platform. I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory. It would be cumbersome to go and create symlinks in all the projects at this stage, therefore, I also suggest that we will make the architecture default to 'x86_64' when unspecified, and the OS default to 'el7'. That way, 'check_patch.sh.fc25' will be equivalent to 'check_patch.sh.fc25.x86_64', and 'check_patch.sh' will be equivalent to 'check_patch.sh.el7.x86_64'. When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s. Thoughts? Ideas? ( Jira ticket tracking this work: ) ( https://ovirt-jira.atlassian.net/browse/OVIRT-1013 ) -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
Hi, all of that makes sense except this:
When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s.
Do not force a branching model on me, please. We have small packages that either do not need any branches at all or we create the Z stream branch on as needed basis only. For example: mom does not need branches it is always compatible, ovirt-optimizer ever had only one Z stream patch in its history... Please start treating packages as separate entities with independent development space. You are trying to workaround the lack of distgit by forcing us to play with our upstream source code repository. You should stop doing that as you will get into trouble once a first non-gerrit project is accepted to oVirt. (And we have couple of project where GitHub is the primary platform already) The way this is done on Travis for example is much better. Pushes to all branches are monitored and branches with no .travis.yml (or automation dir in our case) are ignored. Martin On Tue, Jan 10, 2017 at 10:31 AM, Barak Korren <bkorren@redhat.com> wrote:
Hi all,
The premise of the CI standard is simple: You (the developers) place simple script in the 'automation' directory, and we (the infa team) take care of making Jenkins run it when it should.
But we haven't been able to fully deliver on this premise yet. Getting a project to work with the CI standard also takes writing some YAML in the 'Jenkins' repo. Even worse, this YAML needs to be maintained over time as new project branches get created, new platforms get targeted, etc.
The core reason behind having to write YAML, is that there are two technical details that we need to know in order to run the CI jobs, but are not specified in a way that allows detecting them automatically. Those details are: 1. The platforms a certain project needs to be built and tested on. 2. The branches of the project that CI needs to look at, and how do they map to an oVirt releases.
We need to specify a way to specify the details above in a way that will allow the CI system to automatically detect them. Here are my ideas on how to do that:
We already have a way to specify platforms in the 'automation' directory: scripts and files in the 'automation' directory can be suffixed with a platform name, this make them apply only to that platform.
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
It would be cumbersome to go and create symlinks in all the projects at this stage, therefore, I also suggest that we will make the architecture default to 'x86_64' when unspecified, and the OS default to 'el7'. That way, 'check_patch.sh.fc25' will be equivalent to 'check_patch.sh.fc25.x86_64', and 'check_patch.sh' will be equivalent to 'check_patch.sh.el7.x86_64'.
When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s.
Thoughts? Ideas?
( Jira ticket tracking this work: ) ( https://ovirt-jira.atlassian.net/browse/OVIRT-1013 )
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 10 January 2017 at 12:22, Martin Sivak <msivak@redhat.com> wrote:
Hi,
all of that makes sense except this:
When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s.
Do not force a branching model on me, please. We have small packages that either do not need any branches at all or we create the Z stream branch on as needed basis only. For example: mom does not need branches it is always compatible, ovirt-optimizer ever had only one Z stream patch in its history...
Please start treating packages as separate entities with independent development space. You are trying to workaround the lack of distgit by forcing us to play with our upstream source code repository. You should stop doing that as you will get into trouble once a first non-gerrit project is accepted to oVirt. (And we have couple of project where GitHub is the primary platform already)
While packages are separate entities and have independent life cycles, we still need a way to compose and test oVirt as a whole. And the responsibility to determine which version of the package goes into which oVirt release should, in many cases lay on the shoulders of that package maintainer. Having distgit-like solution can be simple enough, but it sounds to me like an overkill in many cases. How would you suggest to solve this?
The way this is done on Travis for example is much better. Pushes to all branches are monitored and branches with no .travis.yml (or automation dir in our case) are ignored.
Travis never concerns itself with full system composition and integration testing, so this is not a useful analogy at all. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
While packages are separate entities and have independent life cycles, we still need a way to compose and test oVirt as a whole. And the responsibility to determine which version of the package goes into which oVirt release should, in many cases lay on the shoulders of that package maintainer.
Having distgit-like solution can be simple enough, but it sounds to me like an overkill in many cases.
How would you suggest to solve this?
Well, what about another text file in the automation directory? use-for.txt with ovirt-x.y and wildcards?
Travis never concerns itself with full system composition and integration testing, so this is not a useful analogy at all.
Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check). Martin On Tue, Jan 10, 2017 at 1:06 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 12:22, Martin Sivak <msivak@redhat.com> wrote:
Hi,
all of that makes sense except this:
When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s.
Do not force a branching model on me, please. We have small packages that either do not need any branches at all or we create the Z stream branch on as needed basis only. For example: mom does not need branches it is always compatible, ovirt-optimizer ever had only one Z stream patch in its history...
Please start treating packages as separate entities with independent development space. You are trying to workaround the lack of distgit by forcing us to play with our upstream source code repository. You should stop doing that as you will get into trouble once a first non-gerrit project is accepted to oVirt. (And we have couple of project where GitHub is the primary platform already)
While packages are separate entities and have independent life cycles, we still need a way to compose and test oVirt as a whole. And the responsibility to determine which version of the package goes into which oVirt release should, in many cases lay on the shoulders of that package maintainer.
Having distgit-like solution can be simple enough, but it sounds to me like an overkill in many cases.
How would you suggest to solve this?
The way this is done on Travis for example is much better. Pushes to all branches are monitored and branches with no .travis.yml (or automation dir in our case) are ignored.
Travis never concerns itself with full system composition and integration testing, so this is not a useful analogy at all.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Tue, Jan 10, 2017 at 2:18 PM, Martin Sivak <msivak@redhat.com> wrote:
While packages are separate entities and have independent life cycles, we still need a way to compose and test oVirt as a whole. And the responsibility to determine which version of the package goes into which oVirt release should, in many cases lay on the shoulders of that package maintainer.
Having distgit-like solution can be simple enough, but it sounds to me like an overkill in many cases.
How would you suggest to solve this?
Well, what about another text file in the automation directory? use-for.txt with ovirt-x.y and wildcards?
Travis never concerns itself with full system composition and integration testing, so this is not a useful analogy at all.
Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check).
What travis does not have is build chains in the sense of multiple jobs by different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...) which can be triggered according to branches and tags. In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1]. Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...) Best Regards, Roman
Martin
On Tue, Jan 10, 2017 at 1:06 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 12:22, Martin Sivak <msivak@redhat.com> wrote:
Hi,
all of that makes sense except this:
When it comes to branches, I think the way to go is to standardize branch names. That standard should probably be something like 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing conventions like the engine`s.
Do not force a branching model on me, please. We have small packages that either do not need any branches at all or we create the Z stream branch on as needed basis only. For example: mom does not need branches it is always compatible, ovirt-optimizer ever had only one Z stream patch in its history...
Please start treating packages as separate entities with independent development space. You are trying to workaround the lack of distgit by forcing us to play with our upstream source code repository. You should stop doing that as you will get into trouble once a first non-gerrit project is accepted to oVirt. (And we have couple of project where GitHub is the primary platform already)
While packages are separate entities and have independent life cycles, we still need a way to compose and test oVirt as a whole. And the responsibility to determine which version of the package goes into which oVirt release should, in many cases lay on the shoulders of that package maintainer.
Having distgit-like solution can be simple enough, but it sounds to me like an overkill in many cases.
How would you suggest to solve this?
The way this is done on Travis for example is much better. Pushes to all branches are monitored and branches with no .travis.yml (or automation dir in our case) are ignored.
Travis never concerns itself with full system composition and integration testing, so this is not a useful analogy at all.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[1] https://github.com/kubevirt/kubevirt/blob/master/.travis.yml
Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check).
What travis does not have is build chains in the sense of multiple jobs by different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...) which can be triggered according to branches and tags.
In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1].
Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...)
Lets not run this into an off-topic 'travis vs. foo' discussion. This is not going anywhere. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
This is on topic. We can (and should) take inspiration in how others are doing it or we will be repeating the mistakes again and again. Travis automation notices pushes to all branches and then uses conditional checks to decide if anything needs to be done. We should do the same and put all that to the automation directory. Including patch testing, building, platforms and publishing. Martin On Tue, Jan 10, 2017 at 2:28 PM, Barak Korren <bkorren@redhat.com> wrote:
Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check).
What travis does not have is build chains in the sense of multiple jobs by different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...) which can be triggered according to branches and tags.
In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1].
Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...)
Lets not run this into an off-topic 'travis vs. foo' discussion. This is not going anywhere.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 10 January 2017 at 15:32, Martin Sivak <msivak@redhat.com> wrote:
This is on topic. We can (and should) take inspiration in how others are doing it or we will be repeating the mistakes again and again.
Travis automation notices pushes to all branches and then uses conditional checks to decide if anything needs to be done. We should do the same and put all that to the automation directory. Including patch testing, building, platforms and publishing.
I still stand behind my assertion that Travis does not do integration. I'll try to clarify what I mean by that. The thing is that Travis always looks at a single repo. AFAIK it never tries to look across different repositories and compose them together to create a final product. You can of-course rig things together so that this sort of happens - you make it upload the artifacts somewhere and then trigger something else to do the composite test. The thing about specifying the oVirt releases in a test file is that this can lead to weird edge cases. Suppose for example we have the same text file in two branches, specifying the same oVirt releases? I'd like the specification to at least guarantee that an oVirt release can take builds from at most one branch. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
The thing about specifying the oVirt releases in a test file is that this can lead to weird edge cases. Suppose for example we have the same text file in two branches, specifying the same oVirt releases? I'd like the specification to at least guarantee that an oVirt release can take builds from at most one branch.
Right, this can indeed be an issue. But the only way you can enforce this without touching repository metadata is to have a separate repo with the publisher configuration. I believe Sandro uses something like that here: https://gerrit.ovirt.org/gitweb?p=releng-tools.git;a=summary You can always chose to trust us to not misconfigure the project like that :) Martin On Tue, Jan 10, 2017 at 2:51 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 15:32, Martin Sivak <msivak@redhat.com> wrote:
This is on topic. We can (and should) take inspiration in how others are doing it or we will be repeating the mistakes again and again.
Travis automation notices pushes to all branches and then uses conditional checks to decide if anything needs to be done. We should do the same and put all that to the automation directory. Including patch testing, building, platforms and publishing.
I still stand behind my assertion that Travis does not do integration. I'll try to clarify what I mean by that. The thing is that Travis always looks at a single repo. AFAIK it never tries to look across different repositories and compose them together to create a final product. You can of-course rig things together so that this sort of happens - you make it upload the artifacts somewhere and then trigger something else to do the composite test.
The thing about specifying the oVirt releases in a test file is that this can lead to weird edge cases. Suppose for example we have the same text file in two branches, specifying the same oVirt releases? I'd like the specification to at least guarantee that an oVirt release can take builds from at most one branch.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Tue, Jan 10, 2017 at 3:17 PM, Martin Sivak <msivak@redhat.com> wrote:
The thing about specifying the oVirt releases in a test file is that this can lead to weird edge cases. Suppose for example we have the same text file in two branches, specifying the same oVirt releases? I'd like the specification to at least guarantee that an oVirt release can take builds from at most one branch.
Right, this can indeed be an issue. But the only way you can enforce this without touching repository metadata is to have a separate repo with the publisher configuration.
I believe Sandro uses something like that here: https://gerrit.ovirt.org/gitweb?p=releng-tools.git;a=summary
Yes, adding exact package version into a specific file under releases worked fine so far and I don't see any issue with that. And I definitely don't want to create branches per oVirt version in smaller projects, because we reuse the same version for multiple oVirt major releases. So adding branch per version is a waste of time, when we can compose repository for a version using text file under releases directory.
You can always chose to trust us to not misconfigure the project like that :)
Martin
On Tue, Jan 10, 2017 at 2:51 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 15:32, Martin Sivak <msivak@redhat.com> wrote:
This is on topic. We can (and should) take inspiration in how others are doing it or we will be repeating the mistakes again and again.
Travis automation notices pushes to all branches and then uses conditional checks to decide if anything needs to be done. We should do the same and put all that to the automation directory. Including patch testing, building, platforms and publishing.
I still stand behind my assertion that Travis does not do integration. I'll try to clarify what I mean by that. The thing is that Travis always looks at a single repo. AFAIK it never tries to look across different repositories and compose them together to create a final product. You can of-course rig things together so that this sort of happens - you make it upload the artifacts somewhere and then trigger something else to do the composite test.
The thing about specifying the oVirt releases in a test file is that this can lead to weird edge cases. Suppose for example we have the same text file in two branches, specifying the same oVirt releases? I'd like the specification to at least guarantee that an oVirt release can take builds from at most one branch.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 11 January 2017 at 08:56, Martin Perina <mperina@redhat.com> wrote:
Yes, adding exact package version
Which is very human-labour intensive and useless for CI. Sandro is a saint for doing this for so long, but I'd rather free his time from such mundane tasks.
into a specific file under releases worked fine so far and I don't see any issue with that.
It never worked for CI or even the nightlys, only for "offcial" builds (Having a different flow for "CI" and "official" is a separate problem all on its own).
And I definitely don't want to create branches per oVirt version in smaller projects, because we reuse the same version for multiple oVirt major releases. So adding branch per version is a waste of time, when we can compose repository for a version using text file under releases directory.
It not like a branch is something that's taking up resources, its just a pointer in git... We could also use tags if that may be more convenient (e.g you tag one commit with a version and everything that follows it goes to that version). I guess a text file under 'automation' is also a viable solution, as long as we can make people understand the strange results that may happen of the same file ends up on two different branches. We can probably even do both - use the "explicit" text file and fall back to "implicit" branch names if its not there.
You can always chose to trust us to not misconfigure the project like that :)
I'm inclined to do so. I know full well though, that we will get complaints when the system does what it was told to do as opposed to what the maintainer wanted... -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Tue, Jan 10, 2017 at 2:28 PM, Barak Korren <bkorren@redhat.com> wrote:
Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check).
What travis does not have is build chains in the sense of multiple jobs by different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...) which can be triggered according to branches and tags.
In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1].
Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...)
Lets not run this into an off-topic 'travis vs. foo' discussion. This is not going anywhere.
Not trying to make any point, except from providing insight how travis is doing it. Since it might be useful.
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On 10 January 2017 at 15:35, Roman Mohr <rmohr@redhat.com> wrote:
different yaml files, but as Martin says the rest is there. What they have is different steps inside one yaml file (setup, pre_script, post_script, deployment, ...) which can be triggered according to branches and tags.
In standard CI, we try to walk a fine line between keeping everything as simple as possible to do (put the script there), and enabling complex behaviour (you can have a specific script for a specific arch, and we're gonna run the whole OST flow once you merge). The easiest thing for us would be to just tell everyone to put a 'Jenkinsfile' in their repo and be done with...
In Kubevirt we also use a .travis.yaml which does testing and releasing based on tags and branches [1].
Note that for more finetuned controls, they also provide a lot of environment variables which you can reference (e.g. branch, tag, ...)
Lets not run this into an off-topic 'travis vs. foo' discussion. This is not going anywhere.
Not trying to make any point, except from providing insight how travis is doing it. Since it might be useful.
Ok, then let me try to say something about the environment variables. One of the design goals of the standard-CI had always been to also enable local reproduction of the CI flow (In case you didn't know, you can use 'muck_runner.sh' to run the CI scripts in almost exactly the same way Jenkins does it). This is why we tend to not provide any more contextual information then you would have while running the script on your laptop. Having said that, its quite easy for us to provide every last bit of information Gerrit has about a given patch. Make concrete requests and we will accommodate. -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
On Tue, Jan 10, 2017 at 11:31:50AM +0200, Barak Korren wrote:
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
I'd suggest a directory per platform. That way you can simply symlink f25 to f24 and copy all the checks.
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:
On Tue, Jan 10, 2017 at 11:31:50AM +0200, Barak Korren wrote:
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
I'd suggest a directory per platform. That way you can simply symlink f25 to f24 and copy all the checks.
I'm guessing this suggestion is in order to avoid having too many symlinks. It seems to me this may not be needed if we keep the existing logic for finding *.packages and *.repos files. Consider the following automation dir content: check_patch.sh check_patch.packages check_patch.sh.fc24 -> check_patch.sh check_patch.sh.fc25 -> check_patch.sh So same checks running on el7, fc25, fc25, with the same packages and with no much duplication and not too many symlinks. Am I missing something? -- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/
Well, what about using check_patch.sh on all platforms unless there is a more specific file? That is future proof unless a bigger incompatibility appears. The same goes for package files with one possible extension. Allow includes of other files. Martin On Tue, Jan 10, 2017 at 2:20 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:
On Tue, Jan 10, 2017 at 11:31:50AM +0200, Barak Korren wrote:
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
I'd suggest a directory per platform. That way you can simply symlink f25 to f24 and copy all the checks.
I'm guessing this suggestion is in order to avoid having too many symlinks. It seems to me this may not be needed if we keep the existing logic for finding *.packages and *.repos files. Consider the following automation dir content:
check_patch.sh check_patch.packages check_patch.sh.fc24 -> check_patch.sh check_patch.sh.fc25 -> check_patch.sh
So same checks running on el7, fc25, fc25, with the same packages and with no much duplication and not too many symlinks. Am I missing something?
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
A separate plarforms.txt file can list all needed platforms (it should allow wildcards to select a subset of all ovirt defaults). The absence of it would mean you want oVirt defaults. An example: *.x86_64 *.ppc ... The short version of all my emails. Use file content for configuration, not repository metadata or direct file names. Martin On Tue, Jan 10, 2017 at 2:23 PM, Martin Sivak <msivak@redhat.com> wrote:
Well, what about using check_patch.sh on all platforms unless there is a more specific file? That is future proof unless a bigger incompatibility appears.
The same goes for package files with one possible extension. Allow includes of other files.
Martin
On Tue, Jan 10, 2017 at 2:20 PM, Barak Korren <bkorren@redhat.com> wrote:
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:
On Tue, Jan 10, 2017 at 11:31:50AM +0200, Barak Korren wrote:
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
I'd suggest a directory per platform. That way you can simply symlink f25 to f24 and copy all the checks.
I'm guessing this suggestion is in order to avoid having too many symlinks. It seems to me this may not be needed if we keep the existing logic for finding *.packages and *.repos files. Consider the following automation dir content:
check_patch.sh check_patch.packages check_patch.sh.fc24 -> check_patch.sh check_patch.sh.fc25 -> check_patch.sh
So same checks running on el7, fc25, fc25, with the same packages and with no much duplication and not too many symlinks. Am I missing something?
-- Barak Korren bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Jan 10, 2017 at 03:20:45PM +0200, Barak Korren wrote:
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden <ewoud+ovirt@kohlvanwijngaarden.nl> wrote:
On Tue, Jan 10, 2017 at 11:31:50AM +0200, Barak Korren wrote:
I suggest we make the platform suffix explicitly required (with a compatibility fall-back, see below), so that to have 'check_patch' run on Fedora 25 for x86_64, one will have to have a 'check_patch.sh.fc25.x86_64' script (or symlink) in the automation directory.
I'd suggest a directory per platform. That way you can simply symlink f25 to f24 and copy all the checks.
I'm guessing this suggestion is in order to avoid having too many symlinks. It seems to me this may not be needed if we keep the existing logic for finding *.packages and *.repos files. Consider the following automation dir content:
check_patch.sh check_patch.packages check_patch.sh.fc24 -> check_patch.sh check_patch.sh.fc25 -> check_patch.sh
So same checks running on el7, fc25, fc25, with the same packages and with no much duplication and not too many symlinks. Am I missing something?
Right, I somehow assumed that there would be more files than check_patch.sh. Then directories make more sense but if it's just a single file then your proposal is fine. However, I would suggest check_patch.fc24.sh rather than the other way around. If you have different files then editors will recognize the .sh extension.
participants (5)
-
Barak Korren -
Ewoud Kohl van Wijngaarden -
Martin Perina -
Martin Sivak -
Roman Mohr