*** jamesmcarthur has quit IRC | 00:06 | |
*** nBorg has quit IRC | 00:49 | |
*** jamesmcarthur has joined #zuul | 01:00 | |
*** jamesmcarthur has quit IRC | 01:17 | |
*** threestrands has joined #zuul | 01:37 | |
*** jamesmcarthur has joined #zuul | 02:17 | |
*** jamesmcarthur has quit IRC | 02:27 | |
*** jank has joined #zuul | 04:19 | |
*** jamesmcarthur has joined #zuul | 04:31 | |
*** jamesmcarthur has quit IRC | 04:35 | |
*** raukadah is now known as chandankumar | 04:59 | |
*** bhavikdbavishi has joined #zuul | 05:17 | |
*** fdegir has quit IRC | 05:40 | |
*** fdegir has joined #zuul | 05:40 | |
*** nBorg has joined #zuul | 06:25 | |
*** jpena|off is now known as jpena | 06:49 | |
*** pcaruana has joined #zuul | 07:06 | |
*** themroc has joined #zuul | 07:11 | |
*** threestrands has quit IRC | 07:18 | |
AJaeger_ | mhu: via depends-on? That only works for repos that are whitelisted in project-config/zuul/main.yaml for the Zuul tenant. | 07:19 |
---|---|---|
*** ofosos has joined #zuul | 07:32 | |
*** gtema has joined #zuul | 07:58 | |
*** hashar has joined #zuul | 08:11 | |
*** badboy has joined #zuul | 08:35 | |
badboy | hi guys | 08:35 |
badboy | I've created a timer trigger pipeline and for some strange reason a script is run for every branch of every repo in Zuul | 08:36 |
badboy | I just want to run in once per 24 hours not X times REPO_COUNT per 24 hours | 08:36 |
mhu | thanks AJaeger_ I'll have a look | 08:39 |
AJaeger_ | badboy: time trigger runs by default for each branch. If you have some config to share, we might have some more comments. | 09:16 |
*** chandankumar has quit IRC | 09:18 | |
*** chandankumar has joined #zuul | 09:19 | |
badboy | AJaeger_ I have a script which should be run once per Zuul instance (not for every repo/branch) | 09:26 |
badboy | AJaeger_it collects all changes pending submission/gating and creates an email | 09:27 |
badboy | AJaeger_ right now it runs (on my dev instance three times: two branches on one repo, a one branch on another repo) | 09:28 |
badboy | AJaeger_ funny thing is that it's only bound to one project (repo) | 09:28 |
AJaeger_ | badboy: and you have that configured via periodic timer? That's not how periodic works, it is used to run a job per repo. | 09:28 |
badboy | AJaeger_ and still runs for the one with only one branch | 09:28 |
badboy | AJaeger_ http://paste.openstack.org/show/769814/ | 09:32 |
badboy | AJaeger_ pending-changes just executes a script which queries gerrit server and sends an email | 09:34 |
AJaeger_ | badboy: so, yes, the script should run only on first-repo - and one invocation per branch. | 09:35 |
AJaeger_ | You could limit it to master with a "branches:" line | 09:35 |
badboy | in the pipelines.yaml? | 09:35 |
AJaeger_ | badboy: in first-repo, use "my-job: branches: master" | 09:36 |
badboy | AJaeger_ like this http://paste.openstack.org/compare/769815/769814/? | 09:38 |
AJaeger_ | badboy: change pending-changes to "pending-changes:", otherwise ok | 09:43 |
AJaeger_ | (indentation of branches might need two more spaces to make yaml happy, please check) | 09:43 |
badboy | AJaeger_ thank you! | 09:46 |
badboy | AJaeger_ the resolution: http://paste.openstack.org/compare/769818/769814/ | 09:47 |
AJaeger_ | yes - still don't know why it run on the other repo. | 09:47 |
* AJaeger_ will be back later... | 09:47 | |
badboy | AJaeger_ my use case is that first-repo has lots and lots of branches but Zuul only covers one therefore I needed to limit the script to only one run | 09:48 |
badboy | AJaeger_ thanks once more | 09:48 |
*** ianw has quit IRC | 10:00 | |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: Improve job and node information banner https://review.opendev.org/677971 | 10:06 |
*** ianw has joined #zuul | 10:08 | |
*** ianw has quit IRC | 10:27 | |
*** ianw has joined #zuul | 10:28 | |
*** ianw has joined #zuul | 10:29 | |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Better error handling for the PagureAPIClient https://review.opendev.org/679746 | 10:33 |
*** ianw has quit IRC | 10:34 | |
*** hashar has quit IRC | 10:35 | |
*** ianw has joined #zuul | 10:36 | |
*** bhavikdbavishi has quit IRC | 10:36 | |
*** ianw_ has joined #zuul | 10:41 | |
*** ianw_ has joined #zuul | 10:43 | |
*** ianw has quit IRC | 10:44 | |
*** ianw has joined #zuul | 10:44 | |
*** tosky has joined #zuul | 10:45 | |
*** ianw has quit IRC | 10:46 | |
*** ianw has joined #zuul | 10:50 | |
*** ianw has quit IRC | 10:52 | |
*** ianw has joined #zuul | 10:52 | |
*** gtema has quit IRC | 11:06 | |
*** hashar has joined #zuul | 11:10 | |
*** bjackman has joined #zuul | 11:12 | |
*** jpena is now known as jpena|lunch | 11:31 | |
*** hashar has joined #zuul | 11:43 | |
*** badboy has quit IRC | 12:08 | |
*** bjackman has quit IRC | 12:09 | |
*** bhavikdbavishi has joined #zuul | 12:13 | |
*** bogdando has joined #zuul | 12:16 | |
bogdando | hi. I have my local zuul & gerrit & nodepool setup, by CI reproducer scrits, reporting "Project test1 not in pipeline <Pipeline check> for change" . Where to check for wrong configs?.. | 12:16 |
bogdando | so it drops it from queue w/o triggering job | 12:17 |
bogdando | zuul.yaml submitted with the change under test http://paste.openstack.org/show/hEHhUycjexbbfDKbPNVy/ | 12:19 |
pabelanger | which branch did you use? | 12:19 |
pabelanger | branches: ^(?!stable/(newton|ocata|pike)).*$ | 12:19 |
bogdando | master | 12:19 |
pabelanger | possible you didn't match | 12:19 |
bogdando | there is also | 12:21 |
bogdando | 2019-09-03 12:09:19,243 - zuul.Pipeline.tripleo-ci-reproducer.check - DEBUG - [e: 8937218a738843e0ad9afd050ee6fa4b] <QueueItem 0x7fcb8795ec88 for <Change 0x7fcb8a933ac8 test1 1001,2> in check> is a failing item because ['it has an invalid configuration'] | 12:21 |
bogdando | at the end | 12:21 |
pabelanger | yah, your vars section doesn't look formatted right | 12:21 |
pabelanger | but, I don't think I have tested nested dicts | 12:21 |
pabelanger | I'm assuming it is okay | 12:22 |
pabelanger | where does tripleo-ci-base-multinode live? | 12:22 |
*** gtema_ has joined #zuul | 12:23 | |
pabelanger | bogdando: if you first add | 12:23 |
pabelanger | https://github.com/ansible/ansible-zuul-jobs/blob/master/zuul.d/project-templates.yaml#L796 | 12:23 |
pabelanger | do your project, and merge, zuul should start to report invalid configurations back to gerrit | 12:24 |
pabelanger | eg: check: jobs: [] | 12:24 |
openstackgerrit | Benedikt Löffler proposed zuul/zuul master: Report retried builds in a build set via mqtt. https://review.opendev.org/632727 | 12:24 |
openstackgerrit | Benedikt Löffler proposed zuul/zuul master: Report retried builds via sql reporter. https://review.opendev.org/633501 | 12:24 |
bogdando | pabelanger: it seems it's zuul.d/tripleo-rdo-base.yaml in zuul-config stored in my local gerrit | 12:25 |
bogdando | but that files looks weirdly formatted and has only tripleo-ci-base-multinode-rdo job defined, not tripleo-ci-base-multinode ... | 12:26 |
*** bjackman has joined #zuul | 12:26 | |
pabelanger | yah, you need to have zuul report back errors, will explain what the issue is with configuration | 12:27 |
pabelanger | even if you add noop-jobs first | 12:28 |
bogdando | pabelanger: thanks! will try that | 12:28 |
*** weshay has joined #zuul | 12:34 | |
*** jpena|lunch is now known as jpena | 12:40 | |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Switch PDF file name to doc-PROJECT.pdf https://review.opendev.org/679777 | 12:43 |
openstackgerrit | Fabien Boucher proposed zuul/zuul master: Better error handling for the PagureAPIClient https://review.opendev.org/679746 | 12:44 |
*** jamesmcarthur has joined #zuul | 12:46 | |
*** bjackman has quit IRC | 12:51 | |
*** dmsimard has quit IRC | 12:56 | |
*** sanjayu_ has quit IRC | 12:58 | |
*** dmsimard has joined #zuul | 12:58 | |
*** bogdando has left #zuul | 12:59 | |
*** sanjayu_ has joined #zuul | 13:02 | |
*** pcaruana has quit IRC | 13:03 | |
*** pcaruana has joined #zuul | 13:34 | |
*** pcaruana has quit IRC | 13:47 | |
*** pcaruana has joined #zuul | 13:57 | |
*** bhavikdbavishi has quit IRC | 14:05 | |
*** pcaruana has quit IRC | 14:07 | |
*** pcaruana has joined #zuul | 14:10 | |
*** sanjayu_ has quit IRC | 14:23 | |
*** michael-beaver has joined #zuul | 14:31 | |
*** bjackman has joined #zuul | 14:44 | |
*** bjackman has quit IRC | 14:50 | |
clarkb | pabelanger: thinking about https://review.opendev.org/#/c/679145/2 and what you said about ceph swift yesterday. We might want to do a coordinated update between my chnage there and an update to the swift logs role to add a per install prefix/suffix to container names to help make them globally unique? | 14:54 |
clarkb | pabelanger: can you confirm that you cannot create containers in vexxost if opendev has already created a container with that name? | 14:55 |
pabelanger | clarkb: sure, need a container name | 14:56 |
*** jank has quit IRC | 14:57 | |
clarkb | pabelanger: logs_00 through logs_09 in ca-ymq-1 exist | 14:58 |
pabelanger | http://paste.openstack.org/show/770138/ | 14:59 |
pabelanger | no work | 15:00 |
clarkb | neat | 15:00 |
clarkb | ok I'll work on that change after meetings and figure out testing | 15:01 |
clarkb | hrm can't use hostname because we can have different executors (or maybe that is good enough) | 15:04 |
clarkb | may need ot think about the best way to approach this | 15:04 |
*** gtema_ has quit IRC | 15:18 | |
*** hashar has quit IRC | 15:21 | |
*** pcaruana has quit IRC | 15:27 | |
clarkb | I think what we need is a zuul installation identifier that we can add as a container name suffix | 15:28 |
clarkb | (or prefix) | 15:28 |
clarkb | but I'm not seeing anything like that in place already | 15:28 |
clarkb | other options: use the executor hostname (then we'll just get more containers), maybe hash it | 15:29 |
clarkb | set the site identifer as a role var and users can set it if using an object store that requires globally unique container names | 15:30 |
clarkb | this last option is simpliest to implement | 15:31 |
clarkb | and would be backward compatible with adding functionality to zuul itself to have a site identifier (we could set the default var value to that site identifier) | 15:32 |
*** chandankumar is now known as raukadah | 15:32 | |
*** bjackman has joined #zuul | 15:33 | |
*** themroc has quit IRC | 15:37 | |
*** tosky_ has joined #zuul | 15:40 | |
*** tosky has quit IRC | 15:41 | |
*** tosky_ is now known as tosky | 15:41 | |
*** bjackman has quit IRC | 15:42 | |
*** bjackman has joined #zuul | 15:43 | |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Document globally unique container name requirement https://review.opendev.org/679814 | 15:47 |
*** bjackman has quit IRC | 15:47 | |
clarkb | pabelanger: ^ ok I think that is the simplest thing for now. The role supports dealing with this but does require some configuration (so add docs for that) | 15:47 |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Add option for object store friendly log paths https://review.opendev.org/679145 | 16:00 |
clarkb | now to see if I ansibled properly for testing that other related change | 16:00 |
*** sgw has quit IRC | 16:04 | |
*** noorul has joined #zuul | 16:08 | |
*** jpena is now known as jpena|off | 16:13 | |
noorul | Hi | 16:21 |
noorul | Can someone help me to setup ARA reporting? | 16:21 |
dmsimard | noorul: what's up ? | 16:22 |
noorul | dmsimard: Looking for a document to integrate ARA with Zuul | 16:23 |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Add option for object store friendly log paths https://review.opendev.org/679145 | 16:24 |
dmsimard | noorul: I don't think there's a whole lot of docs on that topic but we can improve that. Are you using the ara-report role ? | 16:25 |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Add option for object store friendly log paths https://review.opendev.org/679145 | 16:26 |
noorul | dmsimard: https://etherpad.openstack.org/p/rWL36RmF6W line 168 | 16:27 |
*** hashar has joined #zuul | 16:28 | |
pabelanger | noorul: https://github.com/ansible/project-config/blob/master/zuul.d/jobs.yaml#L37 are the values we setup for ara-report, note ara_report_executable needs to point to the copy inside the executor venv | 16:30 |
noorul | pabelanger: I am looking for steps to setup ARA | 16:31 |
pabelanger | it should be installed by default, IIRC | 16:31 |
dmsimard | noorul: unless mistaken, ara is installed by default in the virtualenvs alongside ansible | 16:31 |
pabelanger | isn't it part of zuul ansible setup now? | 16:31 |
pabelanger | https://opendev.org/zuul/zuul/src/branch/master/zuul/lib/ansible-config.conf | 16:32 |
pabelanger | yah | 16:32 |
pabelanger | so, should be inside ansible venv, on executor | 16:32 |
pabelanger | you likely just need to setup ara path | 16:32 |
noorul | I see multiple ansible version folders under /var/lib/zuul | 16:33 |
pabelanger | yup, that is all the version of ansible, that zuul jobs will be able to use | 16:33 |
noorul | s/version/versions | 16:33 |
noorul | I don't see any virtualenv under them | 16:34 |
dmsimard | noorul: does ara-report fail ? are you seeing any errors ? | 16:34 |
dmsimard | noorul: the virtualenvs are set up inside the workspace at the beginning of the job | 16:34 |
noorul | dmsimard: So every time ara is installed in the virtual env? | 16:35 |
noorul | dmsimard: I don't see /opt/venv folder also | 16:35 |
pabelanger | /opt/venv is site specific, we do that for zuul.a.c | 16:37 |
dmsimard | noorul: /opt/venv is probably from pabelanger's environment | 16:37 |
dmsimard | noorul: the virtualenv dependencies are in https://opendev.org/zuul/zuul/src/branch/master/zuul/lib/ansible-config.conf | 16:37 |
pabelanger | you can just switch that to /var/lib/zuul/ | 16:37 |
dmsimard | brb in a bit, lunch | 16:38 |
noorul | Which is the default location? | 16:39 |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Add option for object store friendly log paths https://review.opendev.org/679145 | 16:39 |
*** brennen|afk is now known as brennen | 16:40 | |
pabelanger | /var/lib/zuul/ansible/ I think | 16:40 |
clarkb | noorul: pabelanger the default depends on how you run the installs :/ | 16:41 |
clarkb | /usr/lib/zuul/ansible if you run the manage venvs command | 16:41 |
clarkb | if however you let zuul install at startup it will go to /var/lib/zuul/ansible-bin iirc | 16:42 |
pabelanger | oh, that is odd | 16:42 |
noorul | Followed https://zuul-ci.org/docs/zuul/admin/zuul-from-scratch.html | 16:42 |
noorul | https://zuul-ci.org/docs/zuul/admin/zuul_install.html | 16:43 |
noorul | I think I ran sudo zuul-manage-ansible | 16:43 |
clarkb | noorul: the zuul-manage-ansible command will install to /usr/lib/zuul/ansible by default | 16:43 |
noorul | clarkb: cool, I see that | 16:44 |
noorul | clarkb: Also the log files are getting compressed by default. Is there an option to disable that? | 16:49 |
clarkb | noorul: that will depend on how you are collecting the logs I think. | 16:50 |
clarkb | do you know what role(s) you are using forthat? | 16:50 |
pabelanger | noorul: http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-October/000565.html might be of interest | 16:51 |
noorul | Line 205 https://etherpad.openstack.org/p/rWL36RmF6W | 16:51 |
pabelanger | noorul: yah, you'll want something like https://review.opendev.org/567696/ | 16:52 |
noorul | pabelanger: It recommends compressing | 16:52 |
noorul | pabelanger: If I compress then browser cannot display that inline | 16:53 |
pabelanger | right, that is what my ML post is about | 16:53 |
pabelanger | you need to update log server to support gzip | 16:53 |
pabelanger | which is an extra step | 16:53 |
pabelanger | and IMO, day 2 operation | 16:53 |
noorul | pabelanger: I have gzip enabled on nginx | 16:54 |
noorul | pabelanger: I think I am missing something on nginx side | 16:55 |
noorul | pabelanger: Is that PR a WIP? | 16:55 |
pabelanger | yes, you need to decompress .gz files and browser will load them | 16:57 |
noorul | pabelanger: In the ML thread, clarkb proposed to improve the doc. Is it available now? | 16:58 |
noorul | pabelanger: I mean example nginx config | 16:58 |
clarkb | I don't remember offering to improve nginx docs | 17:00 |
clarkb | I pushed changes for a bunch of other things though that merged | 17:00 |
noorul | Is anyone familiar with configuring nginx to decompress? | 17:01 |
pabelanger | you need to add a new location, wild card for log.gz files, then gzip off, and add type of text/plain, IIRC | 17:05 |
noorul | pabelanger: I will try that | 17:05 |
openstackgerrit | Clark Boylan proposed zuul/zuul-jobs master: Add option for object store friendly log paths https://review.opendev.org/679145 | 17:05 |
noorul | For ARA after setting the path, ara reporting is still failing | 17:06 |
dmsimard | noorul: what is failing ? What is the error ? | 17:06 |
noorul | dmsimard: I think there is a mistake in my config | 17:07 |
noorul | dmsimard: Let me try fixing it | 17:08 |
*** hashar has quit IRC | 17:13 | |
noorul | dmsimard: It is looking for /usr/lib/zuul/ansible/2.7.13/bin/ara | 17:15 |
clarkb | but ansible/2.7/bin/ara is what exists on disk? | 17:16 |
noorul | dmsimard: On my system it is here /usr/lib/zuul/ansible/2.7/bin | 17:16 |
clarkb | ya so that is a bug in the role I think | 17:16 |
clarkb | or a mismatch in expectations between how zuul installs ansible and ara and the ara role | 17:16 |
noorul | {{ ansible_version.full }} | 17:18 |
noorul | {{ ansible_version.major }}.{{ ansible_version.minor }} | 17:18 |
noorul | will that work? | 17:18 |
clarkb | corvus: pabelanger https://review.opendev.org/#/c/679145/ should be ready for rereview now. It is tested | 17:19 |
clarkb | noorul: yes I think so | 17:19 |
*** mattw4 has joined #zuul | 17:21 | |
AJaeger_ | could I get another review for a zuul-jobs change, please? https://review.opendev.org/679777 | 17:22 |
*** hogepodge has left #zuul | 17:24 | |
noorul | he he | 17:26 |
noorul | at last ARA report is generated | 17:26 |
*** mattw4 has quit IRC | 17:29 | |
*** pcaruana has joined #zuul | 17:29 | |
*** hashar has joined #zuul | 17:30 | |
noorul | dmsimard clarkb pabelanger Thank you! | 17:31 |
*** noorul has quit IRC | 17:33 | |
*** mattw4 has joined #zuul | 17:34 | |
*** jamesmcarthur has quit IRC | 18:19 | |
*** tosky has quit IRC | 18:24 | |
*** jamesmcarthur has joined #zuul | 18:47 | |
*** igordc has joined #zuul | 19:02 | |
*** AJaeger_ is now known as AJaeger | 19:03 | |
*** jamesmcarthur has quit IRC | 19:04 | |
*** jamesmcarthur has joined #zuul | 19:20 | |
*** sgw has joined #zuul | 19:37 | |
*** michael-beaver has quit IRC | 19:40 | |
*** hashar has quit IRC | 19:50 | |
*** pcaruana has quit IRC | 20:00 | |
*** jamesmcarthur has quit IRC | 20:27 | |
*** jamesmcarthur has joined #zuul | 20:30 | |
openstackgerrit | Merged zuul/zuul-jobs master: Switch PDF file name to doc-PROJECT.pdf https://review.opendev.org/679777 | 20:43 |
pabelanger | so, looking at https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/base/post-logs.yaml#L9 I can't figure out how to make that a little more redundant, for example. If upload-logs-swift fails on the random choice, for what ever reason, POST_FAILUREs will be the result | 20:53 |
*** jamesmcarthur has quit IRC | 20:53 | |
pabelanger | given that include_roles are not able to use until / retries, blocks seem to be the next step | 20:53 |
pabelanger | however, I then cannot figure out how to do more then 2 tries, because of block / rescue logic and nested blocks | 20:54 |
pabelanger | I don't think you can use a block in a rescue | 20:54 |
pabelanger | the only other option I can thing of, is passing all the zuul_log_cloud_config into upload-logs-swift then, adding the retries to the task level | 20:55 |
pabelanger | which is a change of functionality, but maybe best option | 20:55 |
pabelanger | adding it to https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/upload-logs-swift/tasks/main.yaml#L19 | 20:56 |
pabelanger | with_random_choice / x times / sleep x seconds | 20:56 |
clarkb | pabelanger: are you specifically wanting to retry with a different cloud? | 20:58 |
pabelanger | yah | 20:58 |
pabelanger | I can retry with same cloud, but that is still a single point of failure | 20:59 |
clarkb | ya so even if you could retry until you'd need some way to remove the failing cloud from the random list | 21:01 |
pabelanger | yah, for start was just to random n+1 of list size | 21:01 |
pabelanger | but could be unlucking and hit same provider multiple times in row | 21:01 |
clarkb | yup | 21:02 |
pabelanger | but, we could pop item off list | 21:02 |
pabelanger | and reassign | 21:02 |
clarkb | are the failures you are experiencing not expected to go away on a subsequent retry? | 21:02 |
clarkb | (just thinking that retrying the same cloud is super easy) | 21:03 |
pabelanger | no, I'd say it would be infra issue. For some reason an outage | 21:04 |
pabelanger | so, really would want to use another cloud in that use case | 21:04 |
*** nBorg has quit IRC | 21:51 | |
fungi | paladox just shared this in #openstack-infra but it's pretty on-topic in here too: https://bugs.chromium.org/p/gerrit/issues/detail?id=11418 | 22:05 |
paladox | Does zuul support http only (that being ssh being optional?) | 22:05 |
clarkb | paladox: I think if you only trigger periodically | 22:06 |
paladox | oh | 22:06 |
clarkb | it can report back via http only (this is how opendev's zuul does it) but it relies on the ssh event stream to get events | 22:06 |
fungi | yeah, it needs ssh access for the gerrit event stream | 22:07 |
fungi | if gerrit implements a non-ssh event stream i'm quite sure zuul would happily add support for it | 22:07 |
paladox | ah ok. I doin't think gerrit-review will be able to use that part (google disabled ssh) | 22:07 |
clarkb | paladox: is the new callback method for gerrit implemented yet? | 22:07 |
fungi | i take it they don't expose an event stream for their gerrit then | 22:07 |
clarkb | if so it probably wouldn't be too had to add support for that to zuul | 22:07 |
paladox | clarkb you mean checkers? | 22:08 |
clarkb | s/had/bad/ | 22:08 |
clarkb | paladox: yes but specifically the bit that calls back to the checkers | 22:08 |
paladox | oh, it's a rest api | 22:08 |
fungi | are checkers expected to poll gerrit periodically then? | 22:08 |
clarkb | paladox: ya there are two ways it can work iirc the first is that checkers poll, the other is checkers register a callbcak endpoint and gerrit calls it on events | 22:08 |
paladox | https://gerrit.googlesource.com/plugins/checks/+/refs/heads/master/resources/Documentation | 22:08 |
clarkb | for zuul the callback method is likely much simpler because zuul wants to be event driven and that is already how the github driver works | 22:09 |
clarkb | adding polling is not impossible but would be new and different so likely more work | 22:09 |
paladox | I'm aware that checkers automatically refreshes it's data in the ui. Not sure about the backend. | 22:09 |
fungi | also polling would be a lot more laggy | 22:09 |
pabelanger | is chromium looking to migrate away from jenkins? | 22:11 |
paladox | chromium is covered by a seperate team so i'm not sure :( | 22:12 |
clarkb | hrm those docs seem to be less helpful than the original spec doc | 22:14 |
clarkb | it isn't clear to me how a checker is supposed to operate from those docs but I seem to remember those two modes of operation with the polling planned to be implemented first | 22:14 |
paladox | https://github.com/GerritCodeReview/gerrit-ci-scripts/commit/ecce2057a3aad4f92898428814bcca185248c4b3 | 22:14 |
clarkb | paladox: what triggers that? | 22:16 |
paladox | if you mean how does thst file get trigger, it gets loaded here https://github.com/GerritCodeReview/gerrit-ci-scripts/blob/91cc091cbeb1f1cb4550c95c403b7bcfda429fcd/jenkins/gerrit-verifier.yaml#L211. If you mean how does it trigger checkers, it doesn't. Checkers collects the results, so the ci is responsible for telling checkers about the results. (that's my understanding). Checkers does support "restart" but not sure how that works with ci.. | 22:18 |
clarkb | ya what tells jenkins to run and execute the build that reports back | 22:18 |
clarkb | that is the part that zuul needs ssh for today | 22:19 |
clarkb | adding support for reporting as checkers should also not be bad | 22:19 |
paladox | yeh | 22:20 |
clarkb | another thing that we might have to reconcilewith checkers is inline comments from CI systems | 22:20 |
clarkb | I'm going to assume that mordred and corvus learned all about this last week though and can fill us in when they return | 22:20 |
paladox | i think that's robot comments | 22:22 |
clarkb | ah ok so submit both a check result and separate robot comments | 22:23 |
clarkb | that makes sense | 22:23 |
paladox | https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#robot-comment-info | 22:23 |
paladox | https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#list-robot-comments | 22:23 |
*** mgoddard has quit IRC | 22:47 | |
*** mgoddard has joined #zuul | 22:47 | |
*** threestrands has joined #zuul | 23:26 | |
*** sgw has quit IRC | 23:44 | |
*** sgw has joined #zuul | 23:45 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!