[01:02:52] 6Phabricator, 15User-JAufrecht: Set up Community Tech to default all tasks to New Work - https://phabricator.wikimedia.org/T122240#1899883 (10JAufrecht) [12:21:26] 6Project-Creators, 6operations: Operations-related subprojects/tags reorganization - https://phabricator.wikimedia.org/T119944#1900694 (10jcrespo) [12:21:30] 6Project-Creators, 10DBA, 10MediaWiki-Database: Rename Database to DBA, create blocked-by-schema-change - https://phabricator.wikimedia.org/T119751#1900692 (10jcrespo) 5Open>3Resolved a:3jcrespo [12:23:51] 6Project-Creators, 6operations: Operations-related subprojects/tags reorganization - https://phabricator.wikimedia.org/T119944#1900696 (10jcrespo) #DBA / #blocked-on-schema-change have been created and documented and in production: https://wikitech.wikimedia.org/wiki/Schema_changes https://wikitech.wikimedia.... [14:18:20] 6Phabricator, 15User-JAufrecht: Set up Community Tech to default all tasks to New Work - https://phabricator.wikimedia.org/T122240#1900872 (10Aklapper) What is requested here exactly? Some [[ https://www.mediawiki.org/wiki/Phabricator/Help/Herald_Rules#Global_Herald_rules | Herald rule ]]? [15:00:14] 6Phabricator: Remove workboard from #revscoring - https://phabricator.wikimedia.org/T122253#1900925 (10Aklapper) Duplicate of T105865 ? Related upstream: https://secure.phabricator.com/T7410 [15:47:43] 6Phabricator: Remove workboard from #revscoring - https://phabricator.wikimedia.org/T122253#1901003 (10Halfak) [15:47:46] 6Phabricator: Delete unused and empty workboards database-side - https://phabricator.wikimedia.org/T105865#1901004 (10Halfak) [15:49:42] 6Phabricator: Remove workboard from #revscoring - https://phabricator.wikimedia.org/T122253#1899575 (10Halfak) Well, I wouldn't call this a duplicate of that bug as it seems this is more specific. It seems that this task may be blocked by that the other. Is it not possible *at all* to delete the workboard via... [15:50:29] 6Phabricator: Delete unused and empty workboards database-side - https://phabricator.wikimedia.org/T105865#1901012 (10Halfak) I just added my own workboard problem as blocked by this. I'd say this is important enough to work on. It makes navigating phab a pain to constantly be shown tiny, unused workboards rat... [17:12:49] anyone have a couple minutes to talk about associating branches/tags in diffusion w/ phab tickets/projects? [17:14:43] twentyafterfour: ^ know a way to associate diffusion commits w/ a task/project automagically? [17:15:11] e.g. https://phabricator.wikimedia.org/rAPIOSd4341ef657c60296a4c273955b2d9a2829e38594 is under a couple of different tags in the same "folder" (alphas) [17:16:06] but it would be great to associate a tag name pattern or branch w/ a phab project (e.g. a release project) so our tickets could be automatically added to it when their corresponding commits are deployed [17:16:30] andre__: ^ [17:17:22] bgerstle: if you mention the task in the commit message, like "refs T123" [17:17:59] twentyafterfour: we could, but we're using GitHub so there are actually multiple commits associated w/ a ticket [17:18:18] our current convention is to put the ticket ID in the branch name (as in the link above) [17:18:26] which actually already gets picked up by diffusion [17:18:44] (there's a mention in the corresponding ticket that something was committed) [17:18:56] twentyafterfour: however, what we really want is to be able to say the code was deployed [17:19:13] e.g. we merge something to master after code review, then QA wants to know when it's ready for testing in a build, and which version(s) to look for [17:19:27] we've gotten closer, now that our Jenkins setup pushes tags for commits that pass the build & deploy pipeline [17:19:40] (you'll see the commit I linked to above has a couple "alphas" tags on it) [17:20:14] what i'm thinking is: we could also push those commits to an "alpha" branch, but i'm wondering if we can associate a specific branch in our repo w/ a phab project [17:21:20] I don't know of a way to associate a branch with a project [17:21:29] ok [17:21:49] you can associate whole repositories with projects [17:22:09] we already did that [17:22:24] i can't edit the repo, so i can't see any add'l options [17:23:41] sorry bgerstle, I'm pretty sick at the moment, not thinking clearly enough to give you a good response. if you can collect this all in a ticket I can try to give you a better response when I'm not completely ill :( [17:23:57] twentyafterfour: sorry you're not feeling well :-( i'll try to put something together [17:24:11] thanks for answering my questions though, already eliminated some possibilities [17:47:47] bgerstle_afk: one way to handle this would be to limit which branches phabricator is tracking. I can specify a fine-grained (regex pattern) of which branches phab will respond to for ticket-association [17:48:52] so e.g. if you only want the ticket to get associated once it's merged to a deployed/* branch then we limit phabricator to only look at deployed/* for ticket association [17:57:56] bgerstle_afk: I sent you an email :) [17:58:43] Just read it, that sounds perfect [17:58:57] twentyafterfour: can you do tags as well, or branches only? [17:59:56] bgerstle_afk: I'm not sure [18:00:02] bgerstle_afk: tags might work [18:01:06] twentyafterfour: I ask because we're already tagging these releases as "alphas/M.m.p.b" [18:01:13] So you can see right away [18:01:23] I can also push to a branch if that's easier [18:03:15] it seems like it only supports branches [18:03:54] K, gimme a minute and I can push to a branch [18:05:52] this is the option I'm thinking of changing: https://phabricator.wikimedia.org/F3139550 [18:06:27] well, not default branch, but "track only" and "autoclose only" [18:07:34] bgerstle_afk: would the branch be alphas/* ? [18:08:50] twentyafterfour: hm, we don't want to close them though [18:08:54] the tickets [18:09:35] bgerstle: right, they only get closed if you say "resolves: T123" in your commit message [18:09:49] twentyafterfour: we usually let QA resolve tickets manually [18:09:50] but if you simply mention the ticket then the association still happens [18:09:55] ah [18:10:10] twentyafterfour: what exactly does association mean in this case? [18:10:42] basically all the current phabricator behavior can be limited to only happen once a commit shows up on a specific branch [18:11:05] "current phab behavior" meaning a comment on the ticket like we have now? [18:11:29] yeah [18:12:22] i see, but there's no way to associate a ticket w/ another project/tag in response to a commit? [18:12:23] and if you say "Refs T123" in the commit message you would get an additional association, where the commit header would actually link to the task and the task would list the commit in the task header as well [18:12:51] e.g. this would say "Wikipedia-iOS-Alpha" after we push a commit w/ that ticket ID to a specific branch (or tag it w/ a specific tag format) https://usercontent.irccloud-cdn.com/file/3ybD3eol/ [18:13:09] hmm you want to add a project to the task? that might be doable with herald rules [18:13:10] ahhh the "refs" sounds interesting [18:13:31] twentyafterfour: i just want QA to be able to easily look at a task and say "has a fix for this deployed?" [18:13:40] right [18:13:43] and ideally "which build version is the fix in?" [18:14:38] we have releasetaggerbot for wikimedia releases, it might be possible to make that support ios releases [18:14:39] twentyafterfour: what does it look like when something w/ "Refs" is committed? [18:15:07] twentyafterfour: i mean: what does its associated task look like? [18:15:45] https://phabricator.wikimedia.org/D20 [18:15:45] https://phabricator.wikimedia.org/T116630 [18:15:55] bgerstle: https://phabricator.wikimedia.org/T89939 is a task with associated commits [18:16:38] see how it lists the commits explicitly in the task [18:17:09] i see.. [18:17:34] so we could do this manually in merge commits [18:17:47] yeah by mentioning the tickets. [18:17:52] but it still doesn't tell you that this was deployed, unless we do what you're saying and only track specific branches (i.e. not master) [18:18:03] we may be able to build herald rules to do what you want as well [18:18:13] yeah, that would be better [18:18:34] because it'd also be nice to know what was deployed in our "beta" channel, as well as production [18:18:41] so having specific release tags/projects for that would be great [18:18:57] again, being able to see specific versions would be cool [18:19:12] https://phabricator.wikimedia.org/rAPIOSd4341ef657c60296a4c273955b2d9a2829e38594 lists all the tags that include this commit [18:19:32] but for the task, we only really need the tag it was initially deployed in—since it's implied that all subsequent tags also include it [18:19:47] if there was a Ruby client for the phab API, we could automate this as one of the build tasks [18:19:48] so you use alpha/* beta/* to denote when some commits are deployed to a particular channel? [18:19:56] twentyafterfour: we're starting to [18:20:08] with the hope that it would help communicate ticket status in phab, but also as an aid for devs [18:20:18] because we usually get asked the ticket status ;_) [18:20:33] the phabricator api is pretty straightforward that may be an option [18:21:10] bgerstle: but it looks like herald rules might do it [18:21:15] ok [18:21:50] twentyafterfour: we might want to do the API eventually, since, in a dream scenario, this process also moves the ticket into the "Needs QA" column [18:21:59] (we use columns to model stages in our dev process atm) [18:22:27] so even if we did all this, we'd still need to go in manually and move the ticket [18:22:37] bgerstle: https://github.com/amfeng/phabricator-ruby looks decent [18:23:00] same for code review (publishing a branch or creating a PR should move a ticket into "Needs Code Review"—which gerrit used to do w/ the "Patch For Review" tag) [18:23:15] indeed.. [18:24:09] bgerstle: I can add projects to a commit based on conditions like the branch.. [18:24:53] can also add auditors if you want to bring commits to attention of people at appropriate times [18:25:04] twentyafterfour: oh that'd be awesome [18:25:21] i.e. deploying to alpha mentions/assigns QA [18:25:27] then it'll show up as needs audit in phabricator [18:25:29] but one step at a time :-) [18:26:54] twentyafterfour: is there a way i can play w/ some of this stuff? [18:27:43] bgerstle: https://phab-01.wmflabs.org/ [18:28:01] twentyafterfour: i meant tweak the herald/repo/project settings? [18:28:18] set up an account and I'll give you enough permissions to play with all of the things [18:28:49] we can even import your git repo into that instance [18:30:05] twentyafterfour: right, but not on the "real" phab instance? [18:30:36] i.e. it'd be nice to be able to tweak this stuff for our project ourselves and ping you if we need help or super privileges or something [18:30:39] well once we get it working I can port the rules over to the real phab instance. We generally try not to experiment too much with the live instance [18:30:45] gotchya [18:30:55] twentyafterfour: that makes perfect sense [18:31:23] I agree you should be able to adjust things yourself but this is actually forging new territory, we've never set up herald rules like this before [18:32:15] twentyafterfour: created: BGerstle_WMF [18:32:20] we've made mistakes before the resulted in sending hundreds of notifications to people or autoclosing a ton of tasks that shouldn't have been. so we've learned it's best not to play with production. [18:32:56] ok you're a superuser on phab-01 now [18:33:23] so you can create global herald rules, import repos, etc. [18:34:13] you should be able to import the IOS repo and create a "global commits rule" to associate projects with commits on a specific branch name (or prefix, etc) [18:37:50] sweet [18:38:05] i'll probably play around w/ that later [18:39:14] twentyafterfour: what's your phab username? want to CC you on this task i'm creating to explore this further [18:39:52] bgerstle: it's mmodell [18:40:00] twentyafterfour: weird, wasn't coming up in autocomplete [18:40:19] oh there we go, needed to omit @ [18:44:34] twentyafterfour: just realized add'l complication... when we deploy builds it might pick up multiple merged branches (and tickets) at once [18:44:41] the more i think about it, the more I think this should be an API thing [18:44:57] hmm [18:45:25] well updating tasks via the api isn't terribly difficult [18:45:29] yeah [18:45:32] and more flexible [18:45:35] (maybe) [18:45:56] herald is pretty flexible too though [18:46:10] i.e. i want to crawl our git history since the last successful build and update ticket statuses which are about to be deployed [18:46:15] or have just be successfully deployed [18:46:44] i'll test it on wmflabs first ;-) [18:47:14] yeah, let me know how it goes, and I'll be glad to help as much as I can [20:29:39] 6Phabricator, 15User-JAufrecht: Set up Community Tech to default all tasks to New Work - https://phabricator.wikimedia.org/T122240#1901830 (10JAufrecht) A custom sql shim in phlogiston. [20:34:01] 6Phabricator, 15User-JAufrecht: Set up Community Tech to default all tasks to New Work - https://phabricator.wikimedia.org/T122240#1901845 (10JAufrecht) To give teams more flexibility, maintenance fraction is derived in Phlogiston, not Phabricator. So it defaults to the worktype tags but can also be calculated... [22:21:12] 6Project-Creators, 7Tracking: [Tracking] Project creation log task - https://phabricator.wikimedia.org/T103700#1902324 (10Krinkle) Created #mediawiki-interwiki and added it to the list on #mediawiki-core.