The RelEng team has been trying to use Differential code review for some of the Scap3 project as a test to work out kinks in that system. mw-tools-scap-tox-doc-publish does not get triggered when we merge new commits using git or arc, as a result the documentation updates we've made to scap have not been published on https://doc.wikimedia.org/mw-tools-scap/
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
As I said in our last team meeting, we should probably just move this to being generated hourly or something instead of being triggered. That's my general position on doc-generation jobs tbh.
Comment Actions
In an ideal world, in the Zuul layout one would just:
- name: mediawiki/tools/scap
test:
- tox-jessie
gate-and-submit:
- tox-jessie
- postmerge:
+ publish:
- mw-tools-scap-tox-doc-publishThe pipelines above reacts to different Gerrit events:
- postmerge on change-merged events which has informations about the change and patchset, this way Zuul reports back on the Gerrit change. Just like when a patch is proposed.
- publish reacts on the Gerrit event ref-updated which is very different and has:
| oldRev | The old value of the ref, prior to the update. |
| newRev | The new value the ref was updated to. |
| refName | Ref name within project. |
| project | Project path in Gerrit. |
Zuul sends different set of parameters as described at http://docs.openstack.org/infra/zuul/launchers.html#zuul-parameters
That might just work.
A way to test on gallium would be to use the Zuul command line client:
$ zuul enqueue-ref --help usage: zuul enqueue-ref [-h] --trigger TRIGGER --pipeline PIPELINE --project PROJECT --ref REF [--oldrev OLDREV] [--newrev NEWREV] optional arguments: -h, --help show this help message and exit --trigger TRIGGER trigger name --pipeline PIPELINE pipeline name --project PROJECT project name --ref REF ref name --oldrev OLDREV old revision --newrev NEWREV new revision
If one change the Zuul layout has above, the master ref update can be simulated with:
zuul enqueue-ref \ --trigger gerrit \ --pipeline publish \ --project mediawiki/tools/scap \ --ref master \ --oldrev 2535ea0c83d431d148c36c13bc61ca331da84f58 \ --new-rev 26544e2ef86315dfa689328d138504d47ccc05ba
Which injects in Zuul an event exactly like if master of mediawiki/tools/scap has been updated from 2535ea0c to 26544e2e.
From there we can look at how well the job behave. It will not be able to report back to Gerrit as is the case with postmerge.