[09:34:04] 6Project-Creators, 10Phabricator-Upstream, 15User-Bd808-Test: Per-user projects for personal work in progress tracking - https://phabricator.wikimedia.org/T555#1764878 (10Hydriz) I would be glad to have this for me as well! [17:51:09] 6Phabricator: Converted bugs could link to the original report in old-bugzilla.wikimedia.org - https://phabricator.wikimedia.org/T882#1765905 (10mmodell) I could make a custom field in phabricator to link it but I don't know how to hook that up to the existing reference field because we didn't use php-backed cus... [18:47:39] @seen 20after4 [18:48:20] mutante: hi [18:48:30] oh, heh :) [18:49:01] twentyafterfour: hi! i'm tempted to merge this: https://gerrit.wikimedia.org/r/#/c/247794/ [18:49:23] but i wasn't sure if it needs a) more reviews b) a restart c) announcement [18:49:54] the commit message and tickets seem like we are just restoring stuff that we had and was broken [18:50:11] mutante: it won't get auto-deployed. I'm fine with it merging though, and I can deploy it [18:50:41] I think more changes will be needed to make it work though [18:50:51] something would have to tell phabricator to use the custom login handler [18:51:09] (probably config?) I'll look into it after my deployment which I'm about to start [18:51:18] oh, so you are about to deploy anyways? [18:51:25] just good timing then [18:51:42] makes sense.. and thank you [18:52:00] ok, since it shouldn't hurt even if phab doesn't use it yet [19:24:01] mutante: right [19:53:32] YuviPanda: so to do post receive hooks you use herald rules [19:53:54] you should have the ability to do that but I might have to make you some sort of admin of something. [19:54:39] yeah, that'd be nice :D [19:54:43] and then I can bug you guys less [19:55:01] https://phabricator.wikimedia.org/herald/new/ [19:55:12] do "commit hook" rules show up as an option on that page? [19:56:26] twentyafterfour: yup! [19:57:37] twentyafterfour: hmm, but 'actions' are super limited. no 'make a HTTP request to' [19:59:21] (I see there are train issues, feel free to treat this as lowest priority convo) [19:59:55] tldr is we can make custom things there and it's not too bad but the majority of UI hooks are going to be in-system stuff [20:00:15] why do you want http request for container things? [20:00:23] I guess to kick off the builds [20:00:24] YuviPanda: I made you a repo admin [20:00:43] YuviPanda: may be better handled lower level not sure [20:00:55] use harbormaster to kick off builds [20:01:10] see that ties it a bit too much into the phab infra no? [20:01:18] actually it's a hook in herald + harbormaster [20:01:18] like, we want to be able to support gh, etc the same way.. [20:01:26] and webhooks type stuff makes that trivialish [20:01:31] (just throwing stuff around) [20:01:37] (nothing set in sand much less stone) [20:01:41] phabricator can follow remote repos [20:02:03] also phabricator has webhooks also [20:02:07] also also [20:03:40] right but then it's gh -> phab -> our system [20:03:43] hmm which might be ok [20:03:50] but still, idk, separating that out seems more prudent [20:03:52] ? [20:04:26] > Executing Builds: Harbormaster can only execute builds in a remote system, like Jenkins. It can not currently host builds. [20:04:28] hmm [20:04:36] (am not going to touch jenkins with a 1000ft pole) [20:05:02] > Currently, the only useful type of build step is "Make HTTP Request", which you can use to make a call to an external build system like Jenkins. Today, most plans should therefor look something like this: [20:05:05] lololol [20:06:15] it's emerging :) [20:09:01] so I guess we could have an independent of all this thing [20:09:07] that just builds docker containers and nothing else [20:16:21] YuviPanda: harbormaster is a way to trigger builds, not host them, although drydock hosts builds and it's almost ready for production use [20:16:51] the main point of harbormaster is to avoid polling a bunch of repos for changes [20:18:08] can we make wikibugs shout when new unbreak! now bugs show up? that would be kinda nice I think [20:19:53] shout = notices? [20:26:55] twentyafterfour: agreed [20:27:01] re UBN! [20:27:43] but, I know some projects use UBN! in different ways, and not every UBN! task in phab is something I care about :) [20:27:51] stupid open collaboration communities! [20:27:52] :P [20:28:10] I filed a bug about adding more configurable filters for what gets thrown into a channel [20:28:52] do you know the special wiki page where people can add themselves to be automatically added as code reviewers? [20:29:00] https://phabricator.wikimedia.org/T117081 [20:29:10] it would be cool like that, wouldn't it? [20:29:21] 10Wikibugs, 6Labs, 10grrrit-wm: puppetize grrrit-wm and wikibugs - https://phabricator.wikimedia.org/T104616#1766487 (10yuvipanda) grrrit-wm is on kubernetes now, wikibugs should be too [20:29:30] the same type of filters can be used for bot [20:29:43] just instead of people and gerrit, it's channels and wikibugs [20:31:33] > Automatic Staging Areas: This is the recommended mechanism for change handoff. This mechanism has not been built yet, so you can not use it. [20:31:35] teehee [20:31:58] YuviPanda: it actually has been partially built. [20:32:16] it basically pushes differential revisions to a remote for ci testing [20:32:29] so that the testing system doesn't have to poll diffusion [20:32:54] (and differential revisions aren't even in diffusion yet so polling wouldn't even work for unmerged patches anytway) [20:33:21] right but that won't be needed for this model I guess since it's purely diffusion based [20:33:40] YuviPanda: right [20:35:00] what you could have is a single endpoint that receives webhook calls from either phab or github (or whatever other thing can support webhooks) and then have that thing do a git clone to build the container [20:35:18] then it would be infrastructure independent [20:35:18] yeah that's what I'm thinking [20:35:26] and that'll also be easier to test [20:35:35] and be less dependent on RelEng [20:35:42] instead of pushing to it you let it pull from wherever [20:36:10] yeah [20:36:15] and harbormaster hooks can easily be set up for phab hosted repos, and those who want to use github can do the same thing essentially [20:36:17] and then my build stuff just has to work with a local git repo [20:36:22] right [20:36:25] and that makes life super easy [20:36:27] and nice to test [20:36:37] and nicely independent of / non-blocked by you guys [20:40:55] I can also require people to push to the phab endpoint actually, since that'll strictly enforce our OSS requirement [20:41:03] but that shouldn't change the architecture :) [20:41:45] let me add some more requirements! [20:43:25] > Supports *blocking* post-receive hooks (eg. Make a HTTP call / run a command on post receive, and send output of that to the pusher. Same behavior as a literal post receive hook in git) [20:43:28] that's more specific [20:44:01] 6Project-Creators: Create new project User-JAufrecht - https://phabricator.wikimedia.org/T116218#1766558 (10JAufrecht) [20:44:25] 6Project-Creators: Create new project User-JAufrecht - https://phabricator.wikimedia.org/T116218#1766561 (10JAufrecht) a:3Aklapper [23:59:31] 6Project-Creators: Creating tag for Voice & Tone - https://phabricator.wikimedia.org/T107593#1767405 (10Legoktm) Still not sure what the point of this tag is, maybe @jrbs can explain?