Re: [openstack-dev] [infra][qa] Empty Build succeeded when filtering jobs
Hello! Please, look at the change: https://review.openstack.org/188383 On 03.06.2015 18:56, James E. Blair wrote: Evgeny Antyshev eantys...@odin.com writes: Some CIs like to narrow their scope to a certain set of files. For that, they specify file mask on per-job basis. So there appear annoying comments with only Build succeeded. (an example complaint: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065367.html) Moreover, most of CIs which don't bother filtering, make lots of comments to doc/unittest changes, which is also wrong. (seehttps://review.openstack.org/#/c/152006, and most of CIs don't run unittests) What if Zuul would not comment when no real jobs run? The only meaningful task that is done is merging the patch, but anyway in case of merge failure there should be Merge failed comment. In case of no objections, I'll make corresponding change in zuul. Sounds good to me. In fact, if you specify no jobs for a project-pipeline in Zuul, it does nothing (which is why we have the noop jobs). Arguably the fact that when the job set reduces to nothing due to filtering the change is still enqueued is a bug. I will note that this may complicate efforts to track the performance of third-party CI systems, especially determining whether they are reporting on all changes. I still think you should make the change; the reporting systems may just need to be a little more sophisticated (perhaps they should only look at changes where OpenStack's CI system ran certain jobs). -Jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Evgeny Antyshev. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][qa] Empty Build succeeded when filtering jobs
Evgeny Antyshev eantys...@odin.com writes: Some CIs like to narrow their scope to a certain set of files. For that, they specify file mask on per-job basis. So there appear annoying comments with only Build succeeded. (an example complaint: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065367.html) Moreover, most of CIs which don't bother filtering, make lots of comments to doc/unittest changes, which is also wrong. (seehttps://review.openstack.org/#/c/152006, and most of CIs don't run unittests) What if Zuul would not comment when no real jobs run? The only meaningful task that is done is merging the patch, but anyway in case of merge failure there should be Merge failed comment. In case of no objections, I'll make corresponding change in zuul. Sounds good to me. In fact, if you specify no jobs for a project-pipeline in Zuul, it does nothing (which is why we have the noop jobs). Arguably the fact that when the job set reduces to nothing due to filtering the change is still enqueued is a bug. I will note that this may complicate efforts to track the performance of third-party CI systems, especially determining whether they are reporting on all changes. I still think you should make the change; the reporting systems may just need to be a little more sophisticated (perhaps they should only look at changes where OpenStack's CI system ran certain jobs). -Jim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [infra][qa] Empty Build succeeded when filtering jobs
Some CIs like to narrow their scope to a certain set of files. For that, they specify file mask on per-job basis. So there appear annoying comments with only Build succeeded. (an example complaint: http://lists.openstack.org/pipermail/openstack-dev/2015-June/065367.html) Moreover, most of CIs which don't bother filtering, make lots of comments to doc/unittest changes, which is also wrong. (seehttps://review.openstack.org/#/c/152006, and most of CIs don't run unittests) What if Zuul would not comment when no real jobs run? The only meaningful task that is done is merging the patch, but anyway in case of merge failure there should be Merge failed comment. In case of no objections, I'll make corresponding change in zuul. -- Best regards, Evgeny Antyshev, Parallels PCS6 CI __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
