Re: [ovirt-devel] Actively triggering of CI jobs
That's nice, but most of us are not aware of all that..
Well, we can do a better job advocating that, I try to mention this almost in any infra/devel thread where 'CI' is mentioned. I'm open to suggestions about how to make developers more aware of the fact that the ultimate power to determine what happens in CI had mostly been placed in their hands...
From what I'm seeing, most of the developers here don't make their patches drafts.. moreover, - personally I didn't even know that it will not trigger jobs if it is a draft. (and I'm not the only one)
We, now you know... Adding 'devel' with hope more devs will read this.
- sometimes I need to label my patches, therefor can't make it a draft
By 'label' you mean set topic? Not sure those are mutually exclusive, 'git review' options seem to indicate they are not. I will look deeper into that.
nowadays we are waiting for the jobs too much to finish. and the reality is that too much jobs shouldn't run at all- despite all of the nice things you guys show here..
I which cases besides the patch not being "ready" (=draft...) should jobs not run?
I still think that it will be a better solution to force the developer to activate the tests manually (by adding a flag when pushing or even doing it with the jenkins client..)
We tried to add the 'workflow' flag for that at some point (It is used by most infra projects), but it was not accepted with any enthusiasm by the devs, you can search back the discussion on 'devel'. -- Barak Korren bkorren@redhat.com RHEV-CI Team
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren@redhat.com> wrote:
That's nice, but most of us are not aware of all that..
Well, we can do a better job advocating that, I try to mention this almost in any infra/devel thread where 'CI' is mentioned. I'm open to suggestions about how to make developers more aware of the fact that the ultimate power to determine what happens in CI had mostly been placed in their hands...
What I'm offering is not letting us a choice, exactly because what you are saying regarding the fact that most of the influence of what happens in CI is in our hands. otherwise what happens is the current situation where some/most of the developers are not aware of their options, or misses the mails or whatever..
From what I'm seeing, most of the developers here don't make their
patches
drafts.. moreover, - personally I didn't even know that it will not trigger jobs if it is a draft. (and I'm not the only one)
Well, now you know... Adding 'devel' with hope more devs will read this.
- sometimes I need to label my patches, therefor can't make it a draft
By 'label' you mean set topic? Not sure those are mutually exclusive, 'git review' options seem to indicate they are not. I will look deeper into that.
nowadays we are waiting for the jobs too much to finish. and the reality is that too much jobs shouldn't run at all- despite all of the nice things you guys show here..
I which cases besides the patch not being "ready" (=draft...) should jobs not run?
Most of the review process doesn't need the jobs to run. a patch has 5-10, and sometimes much more sets until it is being merged- you don't need to run the jobs every single time you are updating your patch..
I still think that it will be a better solution to force the developer to activate the tests manually (by adding a flag when pushing or even doing
it
with the jenkins client..)
We tried to add the 'workflow' flag for that at some point (It is used by most infra projects), but it was not accepted with any enthusiasm by the devs, you can search back the discussion on 'devel'.
The workflow makes job DISABLING optional. I'm suggesting making job ENABLING optional, with some other flag.. As we must run it to merge- it won't be missed, and will be triggered only when needed.
-- Barak Korren bkorren@redhat.com RHEV-CI Team
--VnOTrGv5LmZxna7m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09 12:00, Amit Aviram wrote:
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren@redhat.com> wrote: =20
That's nice, but most of us are not aware of all that..
Well, we can do a better job advocating that, I try to mention this almost in any infra/devel thread where 'CI' is mentioned. I'm open to suggestions about how to make developers more aware of the fact that the ultimate power to determine what happens in CI had mostly been placed in their hands... =20 =20 What I'm offering is not letting us a choice, exactly because what you are saying regarding the fact that most of the influence of what happens in CI is in our hands. otherwise what happens is the current situation where some/most of the developers are not aware of their options, or misses the mails or whatever.. =20 =20
From what I'm seeing, most of the developers here don't make their
patches
drafts.. moreover, - personally I didn't even know that it will not trigger jobs if it i= s a draft. (and I'm not the only one)
Well, now you know... Adding 'devel' with hope more devs will read this.
- sometimes I need to label my patches, therefor can't make it a draft
By 'label' you mean set topic? Not sure those are mutually exclusive, 'git review' options seem to indicate they are not. I will look deeper into that.
nowadays we are waiting for the jobs too much to finish. and the real= ity is that too much jobs shouldn't run at all- despite all of the nice thin= gs you guys show here..
I which cases besides the patch not being "ready" (=3Ddraft...) should jobs not run?
=20 Most of the review process doesn't need the jobs to run. a patch has 5-10, and sometimes much more sets until it is being merged- you don't need to run the jobs every single time you are updating your patch.. =20 =20
I still think that it will be a better solution to force the develope=
r to
activate the tests manually (by adding a flag when pushing or even do= ing it with the jenkins client..)
We tried to add the 'workflow' flag for that at some point (It is used by most infra projects), but it was not accepted with any enthusiasm by the devs, you can search back the discussion on 'devel'. =20 =20 The workflow makes job DISABLING optional. I'm suggesting making job ENABLING optional, with some other flag.. As we must run it to merge- it won't be missed, and will be triggered only when needed.
That's not true, the workflow make job enabling optional, if you don't set = it, it will not run
=20 =20 =20
-- Barak Korren bkorren@redhat.com RHEV-CI Team
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 --VnOTrGv5LmZxna7m Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWZ/9CAAoJEEBxx+HSYmnDB1wIAJ4Zlhlw8xF4sDnmcG8Asilx GgK6KTbiwr12jVMwuy+F7XF+CdoazchbQhl7tglabsgK8sbhKe7gnnBvSsswvxc7 rszIA351Bx4yNrVeRJVaNR7r+22NK9t6hO57mQENtOddNx2NFDYASzbZKRIiNkns XxtjmHqQX7eAWYaOo55zpZ3TxLVBPB1vFPXQEvEXVysOJOzFas2naXfvM8Yoib94 GA1uSITMBsMFQWjR0iYtfcH+B5SrUmOh92DcyKhsJa3QM+mQKOc/tzwmMeOxyUbS ytTWZzcyNmqd/3q3qASZUSVqhTRlmo4QZBfcB0IMLF9f/N1QmIH8ECflMs1TN0c= =Qy57 -----END PGP SIGNATURE----- --VnOTrGv5LmZxna7m--
On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dcaro@redhat.com> wrote:
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren@redhat.com> wrote:
That's nice, but most of us are not aware of all that..
Well, we can do a better job advocating that, I try to mention this almost in any infra/devel thread where 'CI' is mentioned. I'm open to suggestions about how to make developers more aware of the fact that the ultimate power to determine what happens in CI had mostly been placed in their hands...
What I'm offering is not letting us a choice, exactly because what you are saying regarding the fact that most of the influence of what happens in CI is in our hands. otherwise what happens is the current situation where some/most of the developers are not aware of their options, or misses the mails or whatever..
From what I'm seeing, most of the developers here don't make their
patches
drafts.. moreover, - personally I didn't even know that it will not trigger jobs if it is a draft. (and I'm not the only one)
Well, now you know... Adding 'devel' with hope more devs will read
- sometimes I need to label my patches, therefor can't make it a
draft
By 'label' you mean set topic? Not sure those are mutually exclusive, 'git review' options seem to indicate they are not. I will look deeper into that.
nowadays we are waiting for the jobs too much to finish. and the reality is that too much jobs shouldn't run at all- despite all of the nice
On 12/09 12:00, Amit Aviram wrote: this. things
you
guys show here..
I which cases besides the patch not being "ready" (=draft...) should jobs not run?
Most of the review process doesn't need the jobs to run. a patch has 5-10, and sometimes much more sets until it is being merged- you don't need to run the jobs every single time you are updating your patch..
I still think that it will be a better solution to force the
developer to
activate the tests manually (by adding a flag when pushing or even doing it with the jenkins client..)
We tried to add the 'workflow' flag for that at some point (It is used by most infra projects), but it was not accepted with any enthusiasm by the devs, you can search back the discussion on 'devel'.
The workflow makes job DISABLING optional. I'm suggesting making job ENABLING optional, with some other flag.. As we must run it to merge- it won't be missed, and will be triggered only when needed.
That's not true, the workflow make job enabling optional, if you don't set it, it will not run
So I think we should use it :) Why was it rejected?
-- Barak Korren bkorren@redhat.com RHEV-CI Team
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dcaro@redhat.com> wrote: =20
On 12/09 12:00, Amit Aviram wrote:
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren@redhat.com> wrote:
> > [1]: http://www.ovirt.org/CI/Build_and_test_standards > >
That's nice, but most of us are not aware of all that..
Well, we can do a better job advocating that, I try to mention this almost in any infra/devel thread where 'CI' is mentioned. I'm open to suggestions about how to make developers more aware of =
fact that the ultimate power to determine what happens in CI had mostly been placed in their hands...
What I'm offering is not letting us a choice, exactly because what you are saying regarding the fact that most of the influence of what happens = in CI is in our hands. otherwise what happens is the current situation where some/most of the developers are not aware of their options, or misses=
--PxDrs/Fpf4pPiewX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 12/09 14:09, Amit Aviram wrote: the the
mails or whatever..
From what I'm seeing, most of the developers here don't make their
patches
drafts.. moreover, - personally I didn't even know that it will not trigger jobs if = it is a draft. (and I'm not the only one)
Well, now you know... Adding 'devel' with hope more devs will read this.
- sometimes I need to label my patches, therefor can't make it a draft
By 'label' you mean set topic? Not sure those are mutually exclusive, 'git review' options seem to indicate they are not. I will look deeper into that.
nowadays we are waiting for the jobs too much to finish. and the reality is that too much jobs shouldn't run at all- despite all of the nice things you guys show here..
I which cases besides the patch not being "ready" (=3Ddraft...) sh= ould jobs not run?
Most of the review process doesn't need the jobs to run. a patch has 5-10, and sometimes much more sets until it is being merged- you don't need= to run the jobs every single time you are updating your patch..
I still think that it will be a better solution to force the
developer to
activate the tests manually (by adding a flag when pushing or even doing it with the jenkins client..)
We tried to add the 'workflow' flag for that at some point (It is u= sed by most infra projects), but it was not accepted with any enthusiasm by the devs, you can search back the discussion on 'devel'.
The workflow makes job DISABLING optional. I'm suggesting making job ENABLING optional, with some other flag.. As we must run it to merge- it won't be missed, and will be triggered only when needed.
That's not true, the workflow make job enabling optional, if you don't = set it, it will not run
=20 So I think we should use it :) Why was it rejected? =20
Most people that answered just did not like the idea, they though that it was too much extra process for the developer, and that they had enough with the drafts for now.
=20
-- Barak Korren bkorren@redhat.com RHEV-CI Team
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 --PxDrs/Fpf4pPiewX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWmS1BAAoJEEBxx+HSYmnDN+AH/0fCGyEhilR+r6RZihUuohyG 5u8uLjWrRm+lYiKouiSlI8iGQ8baFhPAdTlOSGZ09Gsu3yq+Ai1mppQYkPQojRnJ eMdtSkVvjnVJVxGBxqV405fwuDT2LR0xspRsFVkoi0O7knXWo/N6CkwYKOlA3Kz5 2zO0RtFeLq2YJhAb9M/UrzBIPgLSeTSE4nzpnuF++qfXs/gTdDbrpx5S7yiOgvYQ 3rHiAcL/qQvUfb4Ghah+U01xaAxCZTsbY8rWveuKvOTO6deVLub7zgvcPL8kzZJv 7ehfW97UbnWmCRrooc5ctG/phZAErBztePVs3mWRs57lunR4zRXLdI1trq0vA/U= =JmCf -----END PGP SIGNATURE----- --PxDrs/Fpf4pPiewX--
participants (3)
-
Amit Aviram -
Barak Korren -
David Caro