3:31 a.m.
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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
4:22 a.m.
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(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
6:06 a.m.
On 10 January 2017 at 12:22, Martin Sivak <msivak(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
7:18 a.m.
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(a)redhat.com> wrote:
> On 10 January 2017 at 12:22, Martin Sivak <msivak(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
7:26 a.m.
On Tue, Jan 10, 2017 at 2:18 PM, Martin Sivak <msivak(a)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(a)redhat.com> wrote:
> On 10 January 2017 at 12:22, Martin Sivak <msivak(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
[1] https://github.com/kubevirt/kubevirt/blob/master/.travis.yml
7:28 a.m.
>
> 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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
7:32 a.m.
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(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
7:51 a.m.
On 10 January 2017 at 15:32, Martin Sivak <msivak(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
8:17 a.m.
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(a)redhat.com> wrote:
> On 10 January 2017 at 15:32, Martin Sivak <msivak(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
12:56 a.m.
On Tue, Jan 10, 2017 at 3:17 PM, Martin Sivak <msivak(a)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(a)redhat.com> wrote:
> On 10 January 2017 at 15:32, Martin Sivak <msivak(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:38 a.m.
On 11 January 2017 at 08:56, Martin Perina <mperina(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
7:35 a.m.
On Tue, Jan 10, 2017 at 2:28 PM, Barak Korren <bkorren(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
8:07 a.m.
On 10 January 2017 at 15:35, Roman Mohr <rmohr(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
6:33 a.m.
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.
7:20 a.m.
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden
<ewoud+ovirt(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
7:23 a.m.
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(a)redhat.com> wrote:
On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden
<ewoud+ovirt(a)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(a)redhat.com
RHCE, RHCi, RHV-DevOps Team
https://ifireball.wordpress.com/
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:27 a.m.
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(a)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(a)redhat.com> wrote:
> On 10 January 2017 at 14:33, Ewoud Kohl van Wijngaarden
> <ewoud+ovirt(a)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(a)redhat.com
> RHCE, RHCi, RHV-DevOps Team
> https://ifireball.wordpress.com/
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
8:36 a.m.
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(a)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.
2661
days inactive
2662
days old
17 comments
5 participants
participants (5)
-
Barak Korren -
Ewoud Kohl van Wijngaarden -
Martin Perina -
Martin Sivak -
Roman Mohr