Saturday, 2019-03-30

*** jamesmcarthur has joined #zuul01:21
*** jamesmcarthur has quit IRC01:25
*** jamesmcarthur has joined #zuul04:08
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Delete files in dest that don't exist  https://review.openstack.org/64881504:18
*** jamesmcarthur has quit IRC05:17
*** jamesmcarthur has joined #zuul05:18
*** jamesmcarthur has quit IRC05:22
*** jamesmcarthur has joined #zuul05:48
*** bhavikdbavishi has joined #zuul05:57
*** bhavikdbavishi has quit IRC06:37
*** bhavikdbavishi has joined #zuul06:47
*** bhavikdbavishi has quit IRC06:53
*** jesusaur has quit IRC07:00
*** jesusaur has joined #zuul07:02
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Match tag items against containing branches  https://review.openstack.org/57855707:44
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Use implied branch matcher for implied branches  https://review.openstack.org/64027207:44
*** bhavikdbavishi has joined #zuul07:48
*** quiquell|off has quit IRC08:14
logan-corvus: i'm confused by https://review.openstack.org/#/c/632566/. it breaks a use case where an untrusted application project calls an untrusted deployment project's deploy job in a post pipeline to deploy the application's merged changes. I guess parts of the job could be shifted into a config project to work around this patch. but I'm missing how the patch mitigates the risk of a "independent pre-merge08:21
logan-post-review pipeline" in a project with secrets. sure, other projects can't call the jobs, but wouldn't someone just propose a change to compromise the secrets directly in the project where they are defined if you had this insecure pipeline available? why bother with depends-on? it seems like the pipeline definition is insecure, not the job definition?08:21
*** bhavikdbavishi has quit IRC08:23
logan-putting it another way: i understand the scenario in the story, but I wonder if the scope of this forced allowed-projects restriction could be limited somehow so it doesn't break jobs on systems that don't have that sort of pipeline configuration. I relied on the previous behavior heavily for centralized post-merge deployment jobs and now none of it is permitted to run :)08:36
openstackgerritMerged zuul/project-config master: Add zuul-publish-tox-docs job  https://review.openstack.org/64877708:41
*** pwhalen has quit IRC11:16
*** timburke has quit IRC11:16
*** timburke has joined #zuul11:16
*** bhavikdbavishi has joined #zuul11:25
*** rfolco has quit IRC11:41
*** bhavikdbavishi has quit IRC12:32
*** bhavikdbavishi has joined #zuul13:04
*** bhavikdbavishi has quit IRC13:28
*** bhavikdbavishi has joined #zuul13:29
*** bhavikdbavishi has quit IRC13:35
*** bhavikdbavishi has joined #zuul14:42
corvuslogan-: the idea of an "independent pre-merge post-review pipeline" is that it would be constructed to be secure by only triggering after code review (thus the "post-review" part of the descriptor).  for example, a "secure check" pipeline which runs jobs that test openstacksdk changes against real public clouds with secret credentials after a core reviewer leaves a +2 vote15:00
*** bhavikdbavishi has quit IRC15:00
*** bhavikdbavishi has joined #zuul15:01
corvuslogan-: the vulnerability in that situation is that, even if openstacksdk set allowed-projects to only itself, someone could propose a change to openstacksdk to remove that restriction and print the secret (of course it would never be approved, but that doesn't matter, it only has to exist), then if that person have approval rights to stackforge/stealthekeys, they could propose a change to that which15:05
corvusdepends-on the openstacksdk change, +2 that one, and therefore get it to run a version of the job which exposed secrets.15:05
corvuslogan-: i'd very much like to support the case you describe -- it was very difficult choosing between them and annoying that we couldn't support both.15:06
corvuslogan-: maybe we could do something where adding a job to a project-pipeline in a config project is allowed to override allowed-projects... so all the job definitions could still remain in the untrusted projects, but you attach the deployment job to the application project's post pipeline in the config project.15:08
corvuslogan-: it's too early for me to figure out if that's secure or not, but i'll think about it... what do you think?15:09
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix slightly smaller font of in progress jobs  https://review.openstack.org/64882715:30
pabelangerhttps://review.openstack.org/648815/ is the fix to stale files being left on static nodes (with prepare-workspace), however we don't run this role in openstack zuul. So I just linked downstream results.15:32
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Resolve todo after stream.html to stream renaming  https://review.openstack.org/64882815:33
*** bhavikdbavishi has quit IRC15:37
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Don't create bindep venv if bindep_file is not found  https://review.openstack.org/64883316:28
pabelanger^ is a small speed improvement to deal with projects that don't have bindep.txt files. No need to install bindep into a virtualenv.16:42
AJaegerpabelanger: for OpenStack we have the fallback, so in OpenStack that is a nop. But fine taking it for others17:06
pabelangerAJaeger: thanks!18:06
*** jamesmcarthur has quit IRC18:21
*** jamesmcarthur_ has joined #zuul18:21
*** jamesmcarthur_ has quit IRC18:36
*** rfolco has joined #zuul19:15
logan-corvus: I like that idea. it seems like a workable solution and good middle ground.19:39
*** rfolco has quit IRC19:47
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add trailing slash for log url  https://review.openstack.org/64883720:15
pabelangermnaser: AJaeger: ^ another thing I noticed, shouldn't break anything but give correct log now to users in logs.20:16
*** jamesmcarthur has joined #zuul20:18
*** remi_ness has joined #zuul20:32
*** pwhalen has joined #zuul21:20
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Use xterm.js for live log streaming  https://review.openstack.org/64883821:24
tobiashcorvus, mordred, tristanC: this is an improvement for the browser based live log ^21:25
tobiashwith that my browser handles live logs just fine regardless of the size21:25
tobiash:)21:25
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Use xterm.js for live log streaming  https://review.openstack.org/64883821:27
*** jamesmcarthur has quit IRC22:22
*** remi_ness has quit IRC22:27
SpamapScoooooool22:42
logan-tobiash: that works great!23:34
logan-http://logs.openstack.org/38/648838/2/check/zuul-build-dashboard/51795bc/npm/html/stream/e105d46904794cb8af4b5a63edb70f6c?logfile=console.log even has colors in it23:37

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!