openstackgerrit | Paul Belanger proposed zuul/zuul master: Switch to review.opendev.org for README.rst https://review.opendev.org/676529 | 00:01 |
---|---|---|
*** mattw4 has quit IRC | 00:09 | |
pabelanger | woot | 00:30 |
pabelanger | https://dashboard.zuul.ansible.com/t/ansible/build/b0a8deb72a8741908a19e060d8cdb1e9/console | 00:30 |
pabelanger | corvus: mordred ^ | 00:31 |
*** rfolco has quit IRC | 00:35 | |
*** spsurya has joined #zuul | 01:28 | |
corvus | pabelanger: \o/ | 02:31 |
*** bhavikdbavishi has joined #zuul | 02:42 | |
*** noorul has joined #zuul | 02:45 | |
noorul | hi all | 02:45 |
noorul | I am trying to follow this https://zuul-ci.org/docs/zuul/admin/quick-start.html | 02:45 |
noorul | But I get the following error in the log | 02:45 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: connect: Connection refused | 02:45 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: line 9: /dev/tcp/scheduler/4730: Connection refused | 02:45 |
noorul | I thought docker-compose will start gearman | 02:46 |
noorul | Do we have to manually start gearman? | 02:46 |
*** noorul has quit IRC | 02:49 | |
*** bhavikdbavishi1 has joined #zuul | 02:57 | |
*** bhavikdbavishi has quit IRC | 02:58 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 02:58 | |
pabelanger | corvus: also, https://github.com/ansible-network/windmill-config/pull/495#issuecomment-521495697 report-build-page now enabled too | 03:00 |
*** altlogbot_2 has quit IRC | 03:16 | |
*** altlogbot_2 has joined #zuul | 03:18 | |
*** noorul has joined #zuul | 03:35 | |
noorul | pabelanger: hi | 03:35 |
noorul | pabelanger: Have you seen above mentioned issue before? | 03:35 |
*** noorul has quit IRC | 03:45 | |
*** bjackman_ has joined #zuul | 04:55 | |
*** mgoddard has quit IRC | 05:54 | |
*** bhavikdbavishi has quit IRC | 05:59 | |
*** mgoddard has joined #zuul | 06:01 | |
*** bhavikdbavishi has joined #zuul | 06:45 | |
*** bhavikdbavishi has quit IRC | 07:28 | |
*** sshnaidm|afk is now known as sshnaidm | 09:26 | |
*** zbr|flu is now known as zbr | 09:33 | |
*** jangutter has joined #zuul | 09:51 | |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: Allow ensure-tox to upgrade tox version https://review.opendev.org/676464 | 10:13 |
*** jangutter has quit IRC | 10:41 | |
*** jangutter has joined #zuul | 10:57 | |
*** jangutter has quit IRC | 11:01 | |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Set failed, unreachable, skipped statuses in json plugin https://review.opendev.org/676516 | 11:39 |
*** saneax has joined #zuul | 11:43 | |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Add appending yaml log plugin https://review.opendev.org/623256 | 11:46 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Process yaml log files if they exist https://review.opendev.org/676246 | 11:46 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write errors from ansible execution into yaml log https://review.opendev.org/676250 | 11:46 |
*** rlandy has joined #zuul | 11:46 | |
*** rlandy is now known as rlandy|rover | 11:46 | |
*** saneax has quit IRC | 11:57 | |
*** bhavikdbavishi has joined #zuul | 12:00 | |
*** electrofelix has joined #zuul | 12:01 | |
*** bhavikdbavishi1 has joined #zuul | 12:13 | |
*** rfolco has joined #zuul | 12:14 | |
*** bhavikdbavishi has quit IRC | 12:14 | |
*** bhavikdbavishi1 is now known as bhavikdbavishi | 12:15 | |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: WIP: Allow ensure-tox to upgrade tox version https://review.opendev.org/676464 | 12:18 |
*** bjackman_ has quit IRC | 13:00 | |
openstackgerrit | Paul Belanger proposed zuul/zuul master: Remove support for ansible 2.5 https://review.opendev.org/650431 | 13:20 |
*** jeliu_ has joined #zuul | 13:22 | |
*** bjackman_ has joined #zuul | 13:32 | |
openstackgerrit | Paul Belanger proposed zuul/zuul master: Remove support for ansible 2.5 https://review.opendev.org/650431 | 13:38 |
openstackgerrit | Paul Belanger proposed zuul/zuul master: Switch ansible_default to 2.8 https://review.opendev.org/676695 | 13:38 |
pabelanger | zuul-maint: I'd like to see how we can move forward with ansible 2.8 as the default version of ansible in zuul^. Also drops support for ansible 2.5 too! This is mostly because we are about 2 months away from ansible 2.9 from GA, and using 2.8 for last 2 months, I've not seen any issues. | 13:39 |
pabelanger | https://docs.ansible.com/ansible/latest/roadmap/ROADMAP_2_9.html | 13:39 |
pabelanger | zbr:^ | 13:40 |
SpamapS | I wonder if changing the default ansible version should be a major version bump. | 13:40 |
SpamapS | Probably not, but it should be done with care. | 13:40 |
zbr | pabelanger++ | 13:40 |
pabelanger | SpamapS: I'd say no, only because there is a way for installs to stay on 2.7 | 13:40 |
pabelanger | I also don't think we did bump for 2.7 change too | 13:41 |
openstackgerrit | Paul Belanger proposed zuul/zuul master: WIP: Support Ansible 2.9 https://review.opendev.org/674854 | 13:42 |
pabelanger | and 2.9 support :) | 13:42 |
pabelanger | well, devel, 2.9 should branch in 2 weeks | 13:42 |
SpamapS | So my bar is, can I upgrade without changing configs and expect things to keep working. | 13:43 |
SpamapS | Maybe warnings spew, deprecations and such, but whatever worked on 3.8 needs to work on 3.11. | 13:44 |
SpamapS | pabelanger: You may have seen me ranting like a petulant child in here on a few of those upgrades. ;) | 13:44 |
SpamapS | That's not all Zuul's fault... I'm busy and I don't like having to spend a few hours debugging an upgrade. But for me, I'd like upgrades to be as smooth as possible. | 13:46 |
SpamapS | One thing that would help might be a config upgrader. | 13:46 |
pabelanger | SpamapS: I mean, I'm not against the idea of version bump. But with rate ansible releases software, we'd have one maybe every 6 months | 13:46 |
pabelanger | also | 13:46 |
pabelanger | remote: https://review.opendev.org/676697 Set default-ansible-version to 2.7 for all tenant (minus zuul) | 13:46 |
pabelanger | that is for opendev zuul | 13:46 |
*** bjackman_ has quit IRC | 13:46 | |
SpamapS | Terraform did this for 0.11 -> 0.12. The last release of 0.11 had a thing that would help get things in order before the upgrade. Just something that would look at the zuul config and tell me what's going to change. | 13:47 |
pabelanger | SpamapS: I also think, if your use case, we'd need to freeze zuul-jobs too. For example, there is talks about dropping 2.5 support, so that could also break your zuul. | 13:48 |
SpamapS | zuul-jobs is a whole other thing | 13:48 |
SpamapS | we're moving toward a gated mirror of zuul-jobs | 13:48 |
pabelanger | +1 | 13:49 |
pabelanger | should look into what you are doing :) | 13:49 |
SpamapS | where we'll open a PR and run all of our jobs whenever we detect changes. | 13:49 |
SpamapS | since that has actually been 50% of my table-flips. ;) | 13:49 |
SpamapS | (Sorry, btw, to everyone, for flipping tables in here. It's a nice room and it deserves some nice order. ;) | 13:49 |
pabelanger | over-communication changes is a good thing, I raised the point of ansible default version change on ML, but don't think anybody replied | 13:51 |
pabelanger | so, maybe some sort of warning in logs is next? kinda like ansible on deprecation of things | 13:51 |
pabelanger | but, I would like to make the change | 13:52 |
SpamapS | That's where I think a tool that I could run on my current zuul, that would tell me whats going to change in an upgrade, would be amazing. | 13:52 |
pabelanger | as 2.9 is coming, and would love to have zuul be 2.9 ready same day as ansible release | 13:52 |
SpamapS | Like if it just said "You aren't setting an explicit ansible version on this list of jobs: [...]\nThis will change from 2.7 -> 2.8. That could break things. --> https://ansible.com/release-notes/2.8 | 13:53 |
pabelanger | yah, that would be neat | 13:54 |
pabelanger | in 3.10.0, web.root became required | 13:54 |
pabelanger | is listed in release notes too | 13:54 |
SpamapS | Yeah release notes have been helpful for sure. | 14:00 |
SpamapS | I've caught most things via those. | 14:00 |
SpamapS | But I just wonder if we're holding v4 as this magical reboot internally, when really the users just need to know when it's safe to pull an upgrade in without thinking too hard. | 14:01 |
pabelanger | I under stood v4 as HA schedulers | 14:01 |
pabelanger | or db hard requirement | 14:01 |
SpamapS | Yeah that means we're not staying open to semver | 14:03 |
SpamapS | (did we actually decide to follow semver? ;) | 14:04 |
SpamapS | I feel like changing the way inputs are processed is an "API change" and if you don't change your inputs, but the new version breaks, the new version changed an API in a backward incompatible way. | 14:05 |
SpamapS | Now, I don't know if it would serve the zuul community to be this rigorous. | 14:05 |
SpamapS | If we did that and large chunks of the community stayed on 3.x ... that might be bad for progress. Gentle nudges forward are a good thing. But at the same time.. we're at a tenuous time in the growth of the community... nudges might send people away too. :-P | 14:06 |
* SpamapS is about 50/50 on this one really | 14:06 | |
SpamapS | new topic: Last night our Zuul was down for a few hours because of an errant git connection referenced in our tenant config. | 14:15 |
SpamapS | I'm gathering details, but wanted to ask anyone reading this whether this should be a 3-alarm fire as it was.... | 14:16 |
Shrews | Is there an advantage to zuul's default ansible staying up-to-date with the current ansible release? I can see an advantage to having the default track to the lowest supported ansible version (most pre-written playbooks by folks using zuul are likely targeted to older versions of ansible, not the latest) | 14:16 |
*** noorul has joined #zuul | 14:16 | |
noorul | hi all | 14:16 |
SpamapS | essentially, we set up a new github enterprise, and started pointing zuul at it for trusted configs. We then took that GHE down for #reasons, and nothing broke at the time.. | 14:16 |
SpamapS | but then we restarted zuul-scheduler.. and... it went... poorly. | 14:16 |
SpamapS | I'd like to think that zuul works in such a way where any git connection down is a flood of warnings in the logs and some missing configs | 14:17 |
noorul | I am trying to follow this https://zuul-ci.org/docs/zuul/admin/quick-start.html | 14:17 |
noorul | But I get the following error in the log | 14:17 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: connect: Connection refused | 14:17 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: line 9: /dev/tcp/scheduler/4730: Connection refused | 14:17 |
noorul | I thought docker-compose will start gearman | 14:17 |
SpamapS | but it would appear that's not the case. Could also be github driver specific. | 14:17 |
noorul | Do we have to manually start gearman? | 14:17 |
SpamapS | noorul: gearman is actually just spawned as a child process of zuul-scheduler | 14:18 |
pabelanger | Shrews: in the past, I'd say no, however given ansible releases has become more stable moving to latest version has been way less painful | 14:18 |
Shrews | pabelanger: oh, nm my question... you're only talking about changing the default version for our install. | 14:18 |
pabelanger | yah | 14:18 |
Shrews | i clearly need more caffeine before processing large amounts of scrollback | 14:18 |
pabelanger | noorul: you should check your zuul-scheduler log, so see what is happening | 14:18 |
noorul | pabelanger: ok | 14:19 |
noorul | If I have to write a new driver, is it possible to test it without raising a PR? | 14:19 |
mordred | SpamapS: we did not decide to follow SemVer, if for no other reason than that SemVer is itself derivative and contains zero new or noteworthy thinking and we don't worship at the altar of TPW's ego. that said, I agree that we should bump the major as appropriate and not be special with it | 14:21 |
mordred | SpamapS: I believe we've been very careful about introducing the hard-requirement of a rdbms for that reason, and that when it becomes time to do that I expect that will be a v4 bump for sure | 14:22 |
mordred | the ansible depend complicates this a bit, because ansible EOLs ansibles at a pretty rapid rate | 14:22 |
mordred | so I think it's a fair thing to ponder whether a change in default ansible should trigger a specific versioning event | 14:23 |
mordred | I fear it would be more confusing broadly for it to be a major version event every time we switch the ansible default in an attempt to keep up with the current state of the broader ansible world | 14:23 |
noorul | Is there a guidance to test new driver incrementally | 14:23 |
mordred | hi noorul - I would definitely recommend getting set up to run zuul's tests locally (read the TESTING.rst file in the root of the repo) | 14:24 |
noorul | Is development possible on Mac? | 14:24 |
corvus | the way i've been thinking of versions is that major means the operator will need to change their deployment topology or we're removing features; minor means we're adding features; micro means bugfixes. it's not perfect, and we don't follow it 100%. but also, we're not a library, so it's not like semver matches 100% anyway. i don't think that's incompatible with what SpamapS wants -- i think the major | 14:25 |
corvus | question here is whether to match ansible. | 14:25 |
corvus | honestly, i think the best thing to do is to always do a minor version bump when we change the default version of ansible, and make sure there's a release note so folks are reminded to set their default ansible version if they haven't already. | 14:25 |
mordred | noorul: you might want to look at https://review.opendev.org/#/c/604404/ which was a new driver for pagure - you'll note it has a bunch of tests, all of which should be runnable as part zuul's test suite which you can do locally | 14:26 |
corvus | noorul: i believe some of the dependencies won't work correctly on mac, so i'd recommend at least a linux vm | 14:27 |
mordred | noorul: I would suggest pushing up changes as you go, even if they don't work all the way yet, so we can all talk about the direction you're taking before you get too far | 14:27 |
noorul | I see that the current PR for bitbucket is not using webhooks | 14:28 |
noorul | I am planning to write one using webhooks | 14:28 |
mordred | noorul: the current one is targetting bitbucket enterprise I believe (or whatever the local install is) - perhaps that does not have webhook support? | 14:28 |
noorul | mordred: Our installation is bitbucket server | 14:29 |
corvus | ofosos has been working on that one and can probably answer | 14:29 |
mordred | noorul: ofosos is the person who has been working on that - it would be good to potentially identify what the options are and in what ways we can wind up with one bitbucket driver that works for people - or if we need to have one for local and one for bitbucket.com ... I don't know enough to know if this is the case | 14:29 |
noorul | I will check with ofosos the reasons for not using webhooks | 14:30 |
ofosos | noorul: Im ob Public transit, give me 30 minutes | 14:31 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Add appending yaml log plugin https://review.opendev.org/623256 | 14:33 |
openstackgerrit | Merged zuul/zuul-jobs master: Log errors better in case of unknown REST errors https://review.opendev.org/676476 | 14:39 |
SpamapS | corvus: yeah, that all makes sense. I think maybe we can do some stuff to smooth it out.. Release notes have been pretty good though. | 14:39 |
SpamapS | mordred:ty for the context on semver | 14:39 |
*** noorul has quit IRC | 14:42 | |
openstackgerrit | Merged zuul/zuul-jobs master: Retry more operations https://review.opendev.org/676518 | 14:44 |
*** noorul has joined #zuul | 14:47 | |
*** noorul has quit IRC | 14:52 | |
*** noorul has joined #zuul | 14:57 | |
openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: Create zookeeper operator and zuul CR to k8s test https://review.opendev.org/676458 | 14:58 |
clarkb | for zuul being unhappy when restarting the scheduler and a git source being down that is because zuul wants to load all the configs on start | 15:01 |
*** noorul has quit IRC | 15:02 | |
ofosos | noorul: there we go | 15:02 |
ofosos | So, the logical next step in the driver is to add event driven support | 15:03 |
ofosos | For this we already have variables in place to switch off polling | 15:03 |
clarkb | as for ansible eol the releases arent removed from pypi and since ansible isnt a server there are fewer security concerns in general for using the eol software. All that to say I dont have much issue keeping support foor older ansible. | 15:03 |
fungi | maybe if we used a different word than "support" that could make it more palatable | 15:03 |
ofosos | The idea is to refactor the Watcher class to act as a common base class for the Watcher thread and the event receiver thread | 15:04 |
ofosos | What's your timezone? I'd be available to chat in depth either during the next hour or tomorrow at 6:30pm UTC+2 | 15:05 |
ofosos | Right now we're going to production, I think the stuff we have now works, and we're holding workshops to introduce people to the way we have been using Zuul in our feature team. | 15:05 |
clarkb | ofosos: awesome (re production and workshops) | 15:06 |
ofosos | I think there's a couple of lines of code that I have to push to the PR, including some stuff to make the linter happy | 15:06 |
*** noorul has joined #zuul | 15:07 | |
ofosos | noorul: can you have a look at the channel history :( | 15:08 |
fungi | i think we're about 5 minutes from http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2019-08-15.log.html updating with the things said after 1500z | 15:09 |
fungi | however it can be found in raw text form sooner at the end of http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2019-08-15.log | 15:10 |
ofosos | noorul: tl;dr I'd really like to work on this together. It's not a long way from the current driver to one that supports event driven actions | 15:10 |
*** noorul has quit IRC | 15:11 | |
*** noorul has joined #zuul | 15:11 | |
noorul | ofosos: regarding? | 15:12 |
ofosos | noorul: the Bitbucket driver? | 15:12 |
ofosos | Can you have a look at the channel history? | 15:12 |
fungi | noorul: see the end of http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2019-08-15.log | 15:13 |
noorul | ofosos: Does this scale without event driven? | 15:15 |
noorul | ofosos: Also one of my use case is that I want to trigger a job when a reviewer approves a PR | 15:16 |
ofosos | Event driven does generally scale better. The decision for going polling was based on the initial assumption that we didn't want Users to configure too much stuff, so we opted for this path. Right Now with 10 stash repos connected we don't see any impact at all. | 15:17 |
ofosos | Triggering a job on approve works right now. | 15:17 |
ofosos | Do you want the details on how this works? | 15:17 |
ofosos | Ok, I'll tell you :) | 15:18 |
noorul | ofosos: So you are polling for comment added also? | 15:18 |
noorul | ofosos: We have more than 100 repos | 15:19 |
ofosos | Yes? We also have 100+ repos, but not all of them are on Zuul, and not all of them will in the foreseeable future work with Zuul. | 15:20 |
ofosos | So there's plenty of time to add the event driven stuff. | 15:20 |
noorul | ofosos: Is there a documentation which I can use to quickly try? | 15:21 |
ofosos | That said, you will not get an approval via the comment api, we use the can merge code you can see. This allows the repo maintainer to implement a set of "merge checks" that Bitbucket will handle. So whenever these merge checks Signal that you can merge a pr, we make this Info available in an event and the pipeline can be configure to run the gate and merge the result if the gate is successful | 15:22 |
ofosos | Yes, the PR contains documentation | 15:22 |
ofosos | Do you have time tomorrow? I can walk you through the steps | 15:22 |
noorul | ofosos: Yes | 15:23 |
ofosos | You still need to do some stuff on Bitbucket side. | 15:23 |
ofosos | What's your timezone? | 15:23 |
noorul | UTC+5:30 | 15:23 |
ofosos | I'm pretty booked tomorrow and I might not be available before 4pm UTC+2 | 15:23 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write json log file by seeking and appending https://review.opendev.org/676717 | 15:23 |
mordred | corvus: ^^ how's that look? | 15:24 |
ofosos | We can open end it, if we do it after 6pm UTC+2 | 15:24 |
noorul | ofosos: That is my 7:30 | 15:24 |
noorul | ofosos: I am fine with 6 pm UTC+2 | 15:25 |
noorul | ofosos: That is 9:30 pm IST | 15:25 |
ofosos | Meet here? Then that's probably a great avenue to improve the documentation some more. | 15:25 |
noorul | ok | 15:26 |
ofosos | :) | 15:26 |
fungi | discussing in here would be great, since we get automatic logs which may be nice for others to refer back to as well | 15:26 |
ofosos | Great, you're the first person outside our company to try it (I think). *happy dance* | 15:26 |
ofosos | I'll go over the docs once more tomorrow and I'll have a reference environment to work from. | 15:27 |
openstackgerrit | Jeff Liu proposed zuul/zuul-operator master: Create zookeeper operator and zuul CR to k8s test https://review.opendev.org/676458 | 15:27 |
ofosos | Do.you work off a test environment you control or do you have to involve IT to get users on the Bitbucket Server? | 15:28 |
noorul | ofosos: That will be great | 15:28 |
noorul | ofosos: I installed bitbucket on my Mac laptop today | 15:28 |
noorul | ofosos: I mean free 30 day trial | 15:29 |
noorul | ofosos: I am not sure whether we have a staging environment | 15:29 |
ofosos | Cool, then I think we're all set. You'll need a Bitbucket User for Zuul. We have one with a nice Zuul logo in place :) | 15:29 |
noorul | ofosos: our production environment is maintained by release engineering along with IT | 15:29 |
* mordred is excited and noorul and ofosos some pies | 15:29 | |
ofosos | Everything else should be just Zuul Config. You also need a repo and I'll show you around, what you can/have to do to make it work. | 15:30 |
noorul | I have to demo Zuul's queuing capability, check and gate pipeline (same as openstack), auto merge after successful run | 15:30 |
ofosos | I think we have one missing part in the driver right now, which is cross PR dependencies. | 15:31 |
ofosos | But I also have a Bitbucket installation at home and could reasonably implement that on the weekend. | 15:32 |
noorul | Oh I see | 15:32 |
noorul | But zuul's speculative testing works right? | 15:32 |
ofosos | How are you going to build the Zuul installation? Docker compose? | 15:32 |
noorul | I tried docker-compose today | 15:32 |
noorul | But I get the following error | 15:32 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: connect: Connection refused | 15:33 |
noorul | web_1 | /var/playbooks/wait-to-start-gearman.sh: line 9: /dev/tcp/scheduler/4730: Connection refused | 15:33 |
noorul | 15:33 | |
noorul | Have you seen that | 15:33 |
noorul | This is with your patch | 15:33 |
ofosos | Well, the problem currently is that it'll just ignore any PRs you reference, so no "build this pr with that pr" | 15:33 |
ofosos | I think this looks like a change that has recently landed on master. I think I'll so a rebase first things tomorrow morning. | 15:35 |
noorul | ofosos: Are you also using docker-compose? | 15:35 |
ofosos | No, we have custom deployment code to put Zuul on Kubernetes | 15:36 |
ofosos | We used Docker compose initially | 15:36 |
ofosos | I think it's a good way to get a taste of things. | 15:36 |
noorul | We also have k8s | 15:36 |
noorul | But for demo purpose I think docker-compose should work | 15:37 |
ofosos | Exactly | 15:38 |
corvus | noorul: since the scheduler is responsible for launching gearman, i'd check the logs from the scheduler container and see if there are any clues | 15:38 |
noorul | corvus: I will do that | 15:38 |
noorul | corvus: As soon as I connect to VPN, irc connection will get disconnected | 15:38 |
ofosos | I think there were quite a lot of changes in the startup procedure in Docker compose recently. I thought I rebased after that, but I'm not sure | 15:39 |
noorul | ofosos: Which sha are you using? | 15:39 |
noorul | ofosos: May be I can try that | 15:39 |
corvus | noorul: if you run "docker-compose down" it will delete all the containers, etc, so you can switch to trying master to confirm that it works. but having said that, we do run a gating job based on the docker-compose file, so it should tell us if something is broken, even in the bitbucket patch | 15:41 |
ofosos | noorul: don't have my work laptop at hand | 15:42 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write json log file by seeking and appending https://review.opendev.org/676717 | 15:46 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write errors from ansible execution into json log https://review.opendev.org/676723 | 15:46 |
mnaser | :O | 15:46 |
mnaser | zuul console shows colors? | 15:46 |
mnaser | is this new or am i old | 15:46 |
fungi | probably a little of both | 15:46 |
pabelanger | maybe 2 releases now, when we switched to xterm.js | 15:46 |
mnaser | ~ back in my days, we used to benchmark our browsers render engines ~ | 15:47 |
ofosos | There's one change I have to push. In theory, if you change the commit message and do a force push, there's little reason to rebuild. In practice, changing the commit message will lead Bitbucket to invalidate the current set of builds (force push), so we need to rebuild, even if the only change is the commit message. | 15:47 |
ofosos | That's a small change though. | 15:48 |
ofosos | The things in the PR are already reasonable bug free. We had one problem until last week, that was related to the strange ways, Bitbucket determines if some pull request has been updated or not. | 15:49 |
ofosos | I.e. an approval of a pr, does not change the update timestamp of the PR, so in the version from two weeks ago, you had this kind of problems. | 15:51 |
ofosos | But currently the Bitbucket drive supports configuring "recheck" via comments and can trigger off all pushes, branch pushes and tag pushes | 15:51 |
ofosos | And we're confident enought to hold workshops :) | 15:52 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: WIP: install-openshift: bump version to 3.11.0 https://review.opendev.org/672785 | 15:54 |
ofosos | I don't exactly know what you mean by "speculative test execution" | 15:54 |
ofosos | noorul: ^ | 15:54 |
openstackgerrit | Tristan Cacqueray proposed zuul/nodepool master: DNM: test openshift version bump https://review.opendev.org/672788 | 15:55 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: link the buildset page from the build https://review.opendev.org/675493 | 15:57 |
tristanC | corvus: having the zuul build page linked from the review is super convenient, thanks for all the work on that! | 15:57 |
pabelanger | zuul-build-dashboard npm/html display doesn't seem to work any more | 15:59 |
pabelanger | as it goes to build page, not npm/html folder on log server | 15:59 |
clarkb | you should follow the artifacts from the build page | 16:00 |
pabelanger | yah, before log_url would point directly to it | 16:00 |
corvus | tristanC: yeah, i'm totally addicted. especially since it opens up to your magic thing that tells you what went wrong :) | 16:00 |
*** noorul has quit IRC | 16:01 | |
pabelanger | I'm looking forward to using buildset url on github status link | 16:01 |
clarkb | pabelanger: yes that is a known change but I dont rhink we consider it broken | 16:01 |
corvus | pabelanger: right, with no way to get to the build page. this is a change, but it's deliberate. | 16:01 |
pabelanger | ack | 16:01 |
fungi | indeed, no longer need to edit the url if you want to see the build log instead of the resulting draft | 16:02 |
*** noorul has joined #zuul | 16:03 | |
pabelanger | is there an example of how to use buildset id, in success-url for a pipeline? | 16:04 |
pabelanger | for example: https://dashboard.zuul.ansible.com/t/ansible/buildset/11d8f0f8a3d04abdba0b77a0c347e404 | 16:04 |
corvus | pipelines don't have success urls? | 16:05 |
pabelanger | sorry, status-url | 16:05 |
pabelanger | https://github.com/ansible/project-config/blob/master/zuul.d/pipelines.yaml#L22 | 16:05 |
pabelanger | I think I can use {buildset} in the url | 16:08 |
pabelanger | testing | 16:08 |
corvus | pabelanger: i think it would be {buildset.uuid} | 16:08 |
pabelanger | k | 16:08 |
pabelanger | lets find out :) | 16:09 |
corvus | pabelanger: after you verify that, maybe you could make a patch to make that the default for the github driver? | 16:09 |
corvus | i think that's what everyone actually wants | 16:09 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: manager: specify report failure in logs https://review.opendev.org/671760 | 16:09 |
pabelanger | sure | 16:09 |
pabelanger | a buildset is only report after all tests run, right? | 16:14 |
pabelanger | reported* | 16:14 |
corvus | pabelanger: correct | 16:14 |
corvus | i think we can change that later, when we make the sql reporter fully integrated and required | 16:15 |
corvus | right now we can't have a build page or a buildset page until the entire buildset is completed. in the future, we should be able to display those before completion. | 16:15 |
corvus | but that requires making the sql database not a reporter | 16:16 |
*** noorul has quit IRC | 16:16 | |
pabelanger | np, I left start status-url alone, just updated success / failure | 16:17 |
*** mattw4 has joined #zuul | 16:18 | |
pabelanger | woot! worked | 16:27 |
pabelanger | https://github.com/ansible/project-config/pull/157 | 16:27 |
pabelanger | yay | 16:27 |
corvus | looks good! | 16:29 |
pabelanger | this is something humans have said shippable was better at, so awesome to say we have improvements to show :D | 16:31 |
pabelanger | thank you for all the great work! | 16:31 |
*** sshnaidm is now known as sshnaidm|afk | 16:54 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul-jobs master: install-openshift: bump version to 3.11.0 https://review.opendev.org/672785 | 16:54 |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: WIP: Allow ensure-tox to upgrade tox version https://review.opendev.org/676464 | 16:58 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write json log file by seeking and appending https://review.opendev.org/676717 | 17:01 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Write errors from ansible execution into json log https://review.opendev.org/676723 | 17:01 |
mordred | corvus: I thnik I've satisfied the pep8 gods this time - so am hopefully this run will be green | 17:09 |
openstackgerrit | Sorin Sbarnea proposed zuul/zuul-jobs master: WIP: Allow ensure-tox to upgrade tox version https://review.opendev.org/676464 | 17:09 |
*** electrofelix has quit IRC | 17:10 | |
pabelanger | tobiash: so far, the only thing I am noticing in github driver is following traceback: http://paste.openstack.org/show/757493/ | 17:14 |
pabelanger | aside from that, it is much faster | 17:15 |
pabelanger | we no longer have to worry about ansible/ansible slowing us down | 17:15 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: manager: specify report failure in logs https://review.opendev.org/671760 | 17:27 |
*** saneax has joined #zuul | 17:30 | |
mordred | corvus: https://review.opendev.org/#/c/676717/ is green! | 17:46 |
mordred | tobiash: ^^ that should reduce memory usage on executors a bit by making them not need to read old logs back in to memory | 17:47 |
corvus | mordred: we have tests which read the .json file, right? | 17:48 |
mordred | corvus: we do. they don't do _much_ with it - mostly check that a sentinel value exists | 17:49 |
corvus | yeah, cool -- i see that some of them failed with the earlier errors | 17:49 |
corvus | b' File "/home/zuul/src/opendev.org/zuul/zuul/tests/unit/test_v3.py", line 4922, in test_job_output' | 17:49 |
corvus | b" j[0]['plays'][0]['tasks'][0]" | 17:49 |
corvus | that ^ is good enough for me :) | 17:49 |
mordred | yeah | 17:49 |
corvus | means we're still writing valid json | 17:49 |
mordred | yup | 17:49 |
corvus | i'm +2 on that and the parent | 17:49 |
mordred | woot | 17:50 |
openstackgerrit | Monty Taylor proposed zuul/zuul master: Build wheels with javascript and tarballs without https://review.opendev.org/676470 | 17:51 |
mordred | tristanC: ^^ once that's working, that should get us the thign you were wanting of not having built javascript in the source tarballs | 17:52 |
* mordred needs to send mailing list message | 17:52 | |
tristanC | mordred: thanks :) | 17:56 |
openstackgerrit | Andreas Jaeger proposed zuul/zuul-jobs master: Remove logging of URL in emit-job-header https://review.opendev.org/676746 | 18:07 |
*** rlandy|rover is now known as rlandy|rover|dra | 18:25 | |
*** rlandy|rover|dra is now known as rlandy|drappt | 18:25 | |
*** rfolco is now known as rfolco|rucker|te | 18:25 | |
*** rfolco|rucker|te is now known as rfolco|rucker | 18:25 | |
*** spsurya has quit IRC | 18:53 | |
*** dmsimard has quit IRC | 19:15 | |
*** dmsimard has joined #zuul | 19:23 | |
*** saneax has quit IRC | 19:34 | |
*** gouthamr is now known as gouthamr|brb | 20:02 | |
openstackgerrit | James E. Blair proposed zuul/zuul master: Fix double slash in log browsing https://review.opendev.org/676813 | 20:15 |
corvus | zuul-maint, infra-root: can we have a speedy review of that ^ it's making the new logs page unusable in some cases | 20:16 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: account for header when scrolling to line https://review.opendev.org/676818 | 20:30 |
*** gouthamr|brb is now known as gouthamr | 20:30 | |
*** mattw4 has quit IRC | 20:31 | |
corvus | that's probably less critical, but it's annoying people so would be good to go ahead and merge | 20:31 |
*** mattw4 has joined #zuul | 20:31 | |
*** mattw4 has quit IRC | 20:32 | |
*** rlandy|drappt is now known as rlandy|rover | 20:47 | |
*** rfolco|rucker is now known as rfolco | 20:48 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: extract pure functions from the TaskOutput component https://review.opendev.org/675460 | 20:59 |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: web: test trailing slash are removed from renderTree https://review.opendev.org/676824 | 20:59 |
*** jeliu_ has quit IRC | 21:09 | |
openstackgerrit | Tristan Cacqueray proposed zuul/zuul master: Ensure tenant web_root url has a trailing slash https://review.opendev.org/676826 | 21:10 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: Break log viewer out of the panel https://review.opendev.org/676827 | 21:23 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: add line numbers to log file https://review.opendev.org/676830 | 21:54 |
openstackgerrit | Merged zuul/zuul master: Fix double slash in log browsing https://review.opendev.org/676813 | 21:58 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: add line numbers to log file https://review.opendev.org/676830 | 22:11 |
tristanC | fwiw, the new zuul build page is being integrated in software-factory with https://softwarefactory-project.io/r/16067 and https://softwarefactory-project.io/r/16068 | 22:11 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: account for header when scrolling to line https://review.opendev.org/676818 | 22:12 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: Break log viewer out of the panel https://review.opendev.org/676827 | 22:12 |
openstackgerrit | James E. Blair proposed zuul/zuul master: JS: add line numbers to log file https://review.opendev.org/676830 | 22:12 |
*** igordc has joined #zuul | 23:46 | |
*** rlandy|rover has quit IRC | 23:49 | |
Shrews | ianw: hi! have you seen the comment from corvus on https://review.opendev.org/672196 ? | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!