*** saneax has joined #zuul | 02:29 | |
*** mattw4 has quit IRC | 02:43 | |
*** saneax has quit IRC | 04:12 | |
*** bhavikdbavishi has joined #zuul | 04:40 | |
*** bhavikdbavishi has quit IRC | 05:28 | |
*** armstrongs has joined #zuul | 06:27 | |
*** armstrongs has quit IRC | 06:37 | |
*** ianychoi_ has joined #zuul | 07:06 | |
*** sshnaidm|afk has quit IRC | 07:36 | |
*** sshnaidm|afk has joined #zuul | 07:51 | |
*** sshnaidm|afk has quit IRC | 08:07 | |
*** sshnaidm|afk has joined #zuul | 08:08 | |
*** sshnaidm|afk has quit IRC | 08:53 | |
*** sshnaidm has joined #zuul | 08:55 | |
*** bjackman_ has joined #zuul | 09:00 | |
*** mgoddard has quit IRC | 09:50 | |
*** mgoddard has joined #zuul | 09:51 | |
*** sshnaidm has quit IRC | 10:32 | |
*** sshnaidm has joined #zuul | 10:32 | |
*** altlogbot_3 has quit IRC | 11:43 | |
*** altlogbot_1 has joined #zuul | 11:45 | |
*** noorul has joined #zuul | 11:51 | |
noorul | ofosos: hi | 11:52 |
---|---|---|
noorul | ofosos: hi | 12:08 |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: DNM: Testing emit-role-header change https://review.opendev.org/677090 | 12:16 |
ofosos | hi | 12:17 |
ofosos | noorul: so what's the state of your installation | 12:17 |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: DNM: Testing emit-role-header change https://review.opendev.org/677090 | 12:18 |
noorul | ofosos: I made good progress | 12:23 |
noorul | ofosos: I am testing some use cases now | 12:23 |
noorul | ofosos: one of the use case that I am testing is. Approving PRs with conflicting changes. | 12:24 |
noorul | ofosos: But Zuul is not catching this :( | 12:24 |
ofosos | You mean like in git conflicts? | 12:24 |
noorul | Yes | 12:24 |
ofosos | They should not merge, because Bitbucket catches this | 12:24 |
noorul | ofosos: Zuul is supposed to merge them and test it | 12:25 |
ofosos | How are you going to merge git conflicts? | 12:25 |
noorul | ofosos: Let us not take merge conflict case | 12:25 |
noorul | ofosos: Assume that there is PR1 and PR2 getting developed in parallel | 12:26 |
noorul | ofosos: But PR1 will not work with PR2 | 12:26 |
noorul | ofosos: On approving them parallely zuul is supposed to test them parallely | 12:26 |
noorul | ofosos: PR1 independently and PR1 + PR2 merged together | 12:27 |
noorul | ofosos: I am not seeing that happening | 12:27 |
ofosos | That might be because there's no dependency handling. | 12:28 |
noorul | ofosos: This is same repository | 12:28 |
noorul | ofosos: I don't think for same repository we need dependency handling | 12:28 |
ofosos | Again: there's no dependency handling, not even with PRs in the same repo. | 12:29 |
noorul | Oops! | 12:29 |
ofosos | I'm not sure if zuul should test pr1 + pr2 together, I've never seen that not even on gerrit | 12:29 |
noorul | https://zuul-ci.org/docs/zuul/user/gating.html | 12:30 |
ofosos | I've only ever seen it test my change trains (with dependency handling): test change1, test change1+2, test change 1+2+3,... I've not seen it do that | 12:30 |
ofosos | Do you have a dependent pipeline configured? | 12:31 |
noorul | I think that is what is missing | 12:32 |
noorul | I have to try that | 12:32 |
noorul | Ok, I made gate pipeline dependent pipeline | 12:33 |
ofosos | That behaviour should not depend on the Bitbucket driver | 12:33 |
noorul | Let us see now | 12:33 |
noorul | Yes you are correct | 12:33 |
noorul | Let me test it quickly | 12:33 |
noorul | Another thing I noticed is that sometimes when I resolve conflict and push, the jobs are not queued even waiting for sometime | 12:36 |
noorul | ofosos: In my setup build history is not there | 12:42 |
noorul | ofosos: Is there any specific steps for that | 12:42 |
*** bhavikdbavishi has joined #zuul | 12:44 | |
noorul | It is not working | 12:50 |
noorul | Maybe someone else in the channel can answer | 12:50 |
ofosos | noorul: you need to set the pipeline to report to it and the mariadb driver needs to be configured | 13:01 |
ofosos | In theory, whenever you push you should get a build, but hard to say without looking at the output of the scheduler and the pipeline config | 13:02 |
ofosos | With the parallel testing, probably someone from this channel can help you on monday. | 13:12 |
*** saneax has joined #zuul | 13:13 | |
noorul | ofosos: Here it is https://etherpad.openstack.org/p/rWL36RmF6W | 13:14 |
ofosos | noorul: one thing you have to make sure is, that if you want the check pipeline to run, with you current configuration, check will just run if the pr is not mergeable | 13:19 |
*** saneax has quit IRC | 13:22 | |
noorul | ofosos: I did not get that point | 13:23 |
*** bhavikdbavishi has quit IRC | 13:23 | |
ofosos | Your check pipeline has a requirement canMerge: false. It'll not run if the bitbucket merge checks indicate it is mergeable | 13:24 |
ofosos | Your check pipeline has a requirement canMerge: false. It'll not run if the bitbucket merge checks indicate it is mergeable | 13:24 |
ofosos | Under repo config, go to merge checks, set a condition that there must be at least one approval and one successful build. If the check pipeline is successful, it'll create a successful build, as soon as it is approved it will be mergeable (canMerge=true). After that check will no longer run and only gate will trigger | 13:26 |
ofosos | Like I said on friday/thursday, canMerge is implemented in terms of Bitbucket merge checks | 13:27 |
noorul | ok got it | 13:31 |
noorul | I already had approval enabled | 13:31 |
noorul | Enabled minimum successful build and set to 1 | 13:31 |
noorul | ofosos: Do you think my configs are all ok? | 13:32 |
*** saneax has joined #zuul | 13:32 | |
ofosos | noorul: I would change the gate pipeline trigger comment from "recheck" to "regate" | 13:34 |
fungi | looking at the etherpad, you should be getting change dependencies (including unmerged parents) tested together in the check pipeline, and you should be getting changes approved at roughly the same time tested together in the gate pipeline | 13:35 |
noorul | fungi: It is not working. I have two changes in the same file at the same line approved together | 13:35 |
noorul | fungi: I see in the zuul status, there is a vertical line drawn | 13:35 |
noorul | fungi: But I expect one to fail with merge conflict | 13:36 |
*** bjackman_ has quit IRC | 13:36 | |
fungi | got it. you should be able to tell from the inventory of a build for the second one whether it included the first in the repository it pushed to the job nodes | 13:36 |
fungi | are they for the same branch? | 13:37 |
noorul | fungi: no | 13:37 |
fungi | oh, if they're for different branches then how do they "merge conflict"? | 13:37 |
noorul | fungi: I assume that this is how it works | 13:38 |
noorul | fungi: checkout master | 13:38 |
noorul | fungi: merge PR1 branch | 13:38 |
noorul | fungi: then on top of that merge PR2 branch | 13:38 |
noorul | fungi: Is my assumption wrong? | 13:38 |
fungi | zuul tests by merging pull requests to their target branches. it's possible i don't understand how bitbucket works but in gerrit a change is targeted to a specific branch and that's what zuul tries merging to | 13:39 |
fungi | presumably the pull request indicates somewhere/somehow what branch it should be merged to, right? | 13:40 |
*** saneax has quit IRC | 13:40 | |
noorul | Yes, the master branch | 13:40 |
ofosos | fungi: you create a seperate branch in the same repo and open a pr against master/develop/whatever | 13:40 |
fungi | ahh, so not like github then where you submit pull requests from branches of other repositories | 13:41 |
noorul | fungi: In github also there will be same scenario | 13:42 |
fungi | ahh, okay. i use github only barely more often than bitbucket | 13:42 |
ofosos | fungi: no, that's not usually the workflow. You can do that with private repos, but private repos are not supported by the driver right now. That said, we don't use private spaces, because our installation does not have the correct permissions for this to work. | 13:42 |
noorul | fungi: Let me explain once again | 13:43 |
fungi | so anyway, the pr somehow indicates what branch it should be merged to, which is what i was initially asking: do both pull requests target the same branch (e.g., master)? | 13:43 |
noorul | fungi: Yes, both the PRs target to master branch | 13:43 |
fungi | if they target different branches then zuul won't know it should try combining them | 13:43 |
fungi | if they target the same branch, then the scheduler should over gearman for a merger to try to combine them so that the executor can push the result to the job node | 13:44 |
noorul | Where can I see the log? | 13:44 |
fungi | if the merger is unable to resolve the merge conflicts between them, then the scheduler should report with a failure comment for that buildset | 13:45 |
noorul | fungi: That is not happening | 13:45 |
fungi | are you collecting build logs from the job nodes yet? | 13:46 |
fungi | if so, you can look in the inventory for one of the builds on the second pr to be enqueued and confirm whether it includes the first change | 13:46 |
noorul | fungi: the builds URL is returning 404 for me | 13:46 |
noorul | fungi: That is another problem I am facing | 13:47 |
noorul | web_1 | 2019-08-18 13:47:34,999 INFO cherrypy.access.140354416395656: 10.240.132.90 - - [18/Aug/2019:13:47:34] "GET /api/tenant/demo/builds HTTP/1.1" 404 733 "http://10.29.12.160:9000/t/demo/builds" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0" | 13:47 |
fungi | okay, in that case you can probably work it out from the service logs (the scheduler will log which merger performed the requested merge of those commits, and the log for that merger may contain additional output from the merge process) | 13:47 |
noorul | fungi: Do you know how to configure to make build history work? | 13:50 |
noorul | http://paste.openstack.org/show/759237/ | 13:51 |
noorul | But the build continued and marked a successful | 13:52 |
fungi | for the builds page issue, looks like the api is listening but returning a 404... possible the zuul-web service is logging why those requests fail | 13:52 |
noorul | fungi: Nothing much in the zuul-web service log | 13:54 |
fungi | but on that paste, yes it looks like maybe the bitbucket connection driver is eating merge failures? i will admit i've not had time to dig into the proposed source | 13:54 |
fungi | certainly that BitbucketConnectionError exception looks unexpected | 13:55 |
fungi | and apologies, i have to step away from the keyboard again for probably ~30 minutes | 13:56 |
fungi | oh, though that's attempt 1/4 so maybe it got retried? | 13:57 |
fungi | anyway, back shortly | 13:57 |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 14:10 |
ofosos | fungi: how noorul: I think I know what's wrong. I've pushed a change, let's see how the tests go and then try it out. | 14:10 |
noorul | ofosos: Normally how do you build the containers? | 14:12 |
noorul | ofosos: When I do docker build -f . | 14:12 |
noorul | ofosos: It is not tagging the containers | 14:12 |
ofosos | noorul: fungi: that merge failure is kind of expected. Bitbucket can't merge the pr and returns an exception. Should this be handled differently? | 14:12 |
noorul | ofosos: What is the change for? | 14:13 |
noorul | ofosos: Fixing the merge issue? | 14:13 |
ofosos | No, I think the PRs branch variable should be set to the target branch, we currently set it to the source branch. Can anybody here confirm, that that should be the case. | 14:14 |
AJaeger | ofosos: please update the commit message to explain more on what this fixes and why it's done. That title alone is too little for reviewing | 14:14 |
ofosos | What merge issue? What should we do instead of failing, when those changes cannot be merged on top of each other? | 14:14 |
noorul | ofosos: I think build should not proceed with a merge issue | 14:15 |
ofosos | AJaege, I will. | 14:15 |
noorul | ofosos: Regarding container build, what is your workflow? | 14:15 |
noorul | AJaeger: Do you have any idea how to configure build history? | 14:16 |
ofosos | I don't have the exact docker command at hand. I usually build the containers tag them for ECR and upload to ecr. I've an alias on my work laptop to do this. | 14:19 |
ofosos | noorul, I think the entire problem here is that zuul cannot see which branch these changes are for, so does not merge the testing. I'm trying to change that now. | 14:22 |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 14:24 |
ofosos | AJaeger: done | 14:25 |
AJaeger | noorul: sorry, no idea | 14:29 |
ofosos | Is zuul.openstack slow today? It seems to take a long time to enqueue my tests. | 14:30 |
noorul | ofosos: Can you help with build history? Do you have anything extra other than what is in etherpad in your configs? | 14:36 |
ofosos | noorul: yes you need to configure the mysql reporter for this to work, this needs to be part of your pipeline | 14:38 |
*** noorul has quit IRC | 14:42 | |
*** noorul has joined #zuul | 14:43 | |
noorul | ofosos: Can you share the config? | 14:43 |
ofosos | noorul: I don't have access to that right now. But it should be a simple `mysql:` line in the right place in the pipeline, see https://zuul-ci.org/docs/zuul/admin/drivers/sql.html | 14:44 |
ofosos | Specifically reporter configuration at the end | 14:45 |
fungi | er, 30 minutes is turning into a lot more, but will return soonish i hope | 14:48 |
noorul | I wish there is a complete example L( | 14:49 |
noorul | :( | 14:50 |
noorul | ofosos: How do you build containers from your local changes? | 14:52 |
ofosos | noorul: that example is complete, you just add the name of the mysql connection to the `success:` or `failure:` lists of the pipeline, what else do you need? | 15:07 |
AJaeger | ofosos: http://zuul.opendev.org/t/zuul/status shows 677093 enqueued... | 15:10 |
ofosos | AJaeger, thanks for the quick response, I was looking at the wrong tenant :/ | 15:11 |
noorul | ofosos: Yeah, that worked | 15:15 |
noorul | ofosos: The Change link seems to be incorrect | 15:16 |
noorul | http://10.29.12.160:7990/projects/demo/test/repos/test/browse | 15:16 |
noorul | Shouldn't that be pointing to the PR | 15:17 |
noorul | http://10.29.12.160:7990/projects/DEMO/repos/test/pull-requests/6/overview | 15:17 |
noorul | ofosos: Can you re-base your patch? I think lot of UI enhancements went in recently. I am not able to see the same UI as zuul.opendev.org | 15:23 |
noorul | https://imgur.com/P5YuOdA | 15:23 |
noorul | That is opendev one | 15:23 |
noorul | This is mine https://imgur.com/jbBlJKV | 15:24 |
*** ianychoi_ has quit IRC | 15:26 | |
ofosos | Let me have a look at the change link | 15:32 |
ofosos | noorul: can you post an example change link? | 15:32 |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 15:34 |
noorul | ofosos: What do you mean? | 15:35 |
noorul | The non working example ? | 15:35 |
ofosos | Let's wait for the branch change to test. I made a note w.r.t. the pull url. I'll check that on monday | 15:36 |
noorul | ofosos: Is this re-based to master? | 15:38 |
ofosos | noorul: no | 15:39 |
noorul | ofosos: Can you re-base? | 15:42 |
AJaeger | noorul: we rebase change to HEAD everytime a we enqueue a change - so no need to rebase | 15:47 |
noorul | AJaeger: How do I get the containers with these changes? | 15:49 |
AJaeger | sorry, I'm not a Zuul developer, just use it - and can't help with that. But if Zuul builds a container, it should be current | 15:50 |
noorul | ofosos: How do you get containers with your changes? | 15:51 |
ofosos | noorul: I do `docker build...` in my local checkout | 15:52 |
*** pots has joined #zuul | 15:52 | |
noorul | ofosos: How do you tag them? | 15:52 |
ofosos | noorul: I do `docker tag...` | 15:53 |
noorul | ofosos: How do you identify which image id is for which service? | 15:53 |
ofosos | noorul: I don't have that info at hand, but you can look it up in the docker docs. | 15:54 |
noorul | ofosos: I am now doing it using docker image history and finding out entry point and then tagging | 15:58 |
noorul | ofosos: which is cumbersome | 15:58 |
noorul | ofosos: I thought you had a better way of doing it | 15:58 |
AJaeger | ofosos: Ah, if you build those locally, then no automatic rebasing happens. This is only done by Zuul when testing it | 15:59 |
fungi | okay, back now, sorry, catching up | 16:29 |
fungi | ofosos: yes, i think you've got it, the zuul branch should be whatever branch the request is targeting merge to, not whatever its source branch name was | 16:30 |
fungi | note that there may be jobs in the check pipeline for zuul which build container images, and if so those will be created by merging the series of changes into the current state of the master branch, in which case we likely archive the resulting images and you could test with those... just a sec and i'll check | 16:33 |
fungi | 677093 failed its unit tests by the way, though i haven't looked at why | 16:35 |
fungi | yeah, the "artifacts" section of https://zuul.opendev.org/t/zuul/build/b632628c74734d70ac2806b07be9c4cb has some docker:// urls which presumably work | 16:36 |
fungi | those should be the result of merging the proposed change(s) into master | 16:37 |
*** noorul has quit IRC | 16:52 | |
*** noorul has joined #zuul | 16:52 | |
noorul | fungi: hi | 16:52 |
fungi | hi there | 16:53 |
noorul | fungi: do you have any idea how to setup ara? | 16:53 |
ofosos | fungi: I think some of the assumptions I had previously are hardcoded into the testing code. I removed some and also cleaned up some code. | 16:53 |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 16:53 |
noorul | I have the role applied but it fails with no ara installation found | 16:55 |
fungi | noorul: i think it depends on how you're archiving your build logs (we used to run it as a wsgi app, but now we serve it from a generic object storage service instead, so the way you use the role may vary) | 16:55 |
fungi | oh, and yeah if you're running ara to generate content as part of the job, ara needs to be installed (either by the job or pre-existing on the node) | 16:56 |
noorul | on each node? | 16:56 |
fungi | i believe for opendev we pre-install ara into a virtualenv in our node images | 16:56 |
noorul | oh I see | 16:57 |
noorul | is it on all the nodes? | 16:58 |
noorul | or executor alone? | 16:58 |
clarkb | its on tye executor | 16:58 |
clarkb | in the venvs there. ara should already be a dep for that | 16:58 |
fungi | oh, we do ara content generation on the executors? i was still in the process of pulling up the role source | 16:59 |
noorul | I am using example docker compose | 16:59 |
clarkb | fungi: yes becausethat is where ansible runs | 16:59 |
fungi | got it | 16:59 |
fungi | we install ara on the nodes for jobs which do nested ansible i guess? | 16:59 |
fungi | or maybe that was still an outstanding to-do after the opendev switch to object storage | 17:00 |
noorul | So if I do pip install ara on executor, will I start seeing the logs published? | 17:01 |
*** noorul has quit IRC | 17:04 | |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 17:54 |
*** saneax has joined #zuul | 18:22 | |
*** dustinc has joined #zuul | 18:58 | |
*** jamesmcarthur has joined #zuul | 19:24 | |
*** jamesmcarthur has quit IRC | 19:41 | |
*** jamesmcarthur has joined #zuul | 19:41 | |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 19:45 |
openstackgerrit | Mark Meyer proposed zuul/zuul master: Change branch variable in PR https://review.opendev.org/677093 | 20:08 |
*** jamesmcarthur has quit IRC | 20:39 | |
*** jamesmcarthur has joined #zuul | 20:39 | |
*** jamesmcarthur has quit IRC | 21:27 | |
*** jamesmcarthur has joined #zuul | 21:28 | |
*** jamesmcarthur has quit IRC | 21:33 | |
*** jamesmcarthur has joined #zuul | 21:48 | |
*** jamesmcarthur has quit IRC | 21:57 | |
*** jamesmcarthur has joined #zuul | 22:25 | |
*** jamesmcarthur has quit IRC | 22:33 | |
*** threestrands has joined #zuul | 22:39 | |
*** jamesmcarthur has joined #zuul | 23:39 | |
*** jamesmcarthur has quit IRC | 23:42 | |
*** jamesmcarthur has joined #zuul | 23:42 | |
*** jamesmcarthur has quit IRC | 23:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!