Open Bug 1400295 Opened 2 years ago Updated 1 year ago
Parse try syntax client side in tools/tryselect instead of from the decision task
59 bytes, text/x-review-board-request
Gps recently proposed making it a requirement to use |mach try| for pushing to try server. I have a patch lying around that does just this, so I'm mostly filing this bug so I have a place to upload it as a prototype. We can also use this as a place to solicit feedback from developers. My patch can't land as is as it breaks things like --rebuild/--rebuild-talos and e-mail notifications on failure. But those shouldn't be too hard to fix. Originally I was worried we'd need to update things that parse try syntax outside of the tree, but I realized we can leave the try syntax in the commit message, so these types of things should just keep working as if nothing changed! This means the only blockers are things that actually generate try syntax and push without using |mach try|. At the very least, autoland does this here: https://hg.mozilla.org/hgcustom/version-control-tools/file/tip/autoland/autoland/transplant.py#l48 The other potential push back is from developers who don't use |mach try|. But I don't see any compelling reason why they shouldn't be using it. Anyway, let's at least use this bug to help get the discussion started.
As mentioned in the commit message, this is just a prototype and still isn't ready for review. Here's an example of it in action: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6532af39391f922f002ab9ff1b6d94814c0c4464
Since gps filed bug 1400330 as a meta bug, I'll rename this one to be a bit more technical.
Summary: Require |mach try| to push to tryserver by handling syntax parsing in tools/tryselect → Parse try syntax client side in tools/tryselect instead of from the decision task
Also, we could technically fix this without deprecating try syntax in the commit message. We would just leave try_option_syntax.py in taskgraph and import it from tools/tryselect. So: mach try syntax => try_task_config.json hg push try => try_option_parser.py Benefits of this approach are: 1. All |mach try| subcommands use the same scheduling method. This means they can share the templating mechanism. 2. |mach try synax| will benefit from new features added to |mach try fuzzy| (or other future subcommands). A side benefit of this (from a deprecating try syntax point of view), is that |mach try syntax| will start to gain features that aren't available to regular try syntax. This will give us a carrot to offer developers who otherwise don't see a reason to switch over. The downside to this is that |mach try syntax| and |hg push try| will start diverging and will no longer have the same behaviour. I still think making this switch before deprecating try syntax is the right move, though I can see the argument against it.
You need to log in before you can comment on or make changes to this bug.