1467147 - Ability to add generic targets to |mach watch|

Status: NEW

(Firefox Build System :: General, enhancement)

Description

[Andrew Halberstadt [:ahal]]

|mach watch| is really cool, but it would be even more useful if it wasn't tied to building Firefox and we could implement whatever targets we wanted.

Some use cases off the top of my head:
- Rebuild docs if *.rst is modified
- Rebuild cached taskgraph (used by |mach try|) if taskcluster/** is modified
- Allow developers to add their own custom targets in machrc

On the command line, I think running |mach watch| should default to targets configured in machrc (or the 'build' target if none are specified). Running |mach watch <target>| would kick off only the specified target.

So if I had this in my machrc:
[watch]
build=
docs=

Then after running |mach watch|, modifying a build file would rebuild firefox, and modifying a doc file would rebuild docs.

Maybe custom targets could be defined in separate files and registered via:
[watch]
my-target=path/to/target.yml

Comment 1

[Nick Alexander :nalexander [he/him]]

Interesting idea.

Can you explain what the benefit of using |mach watch| for this will be over using one of the similar services that are general file-system watching trigger mechanisms?  |mach watch build| (in your notation) is better because we use deep knowledge about FasterMake builds to do things that are hard to describe with |mach build ...| and to save Python invocations.  I can imagine that saving Python invocations might be useful more generally, but also harder to prevent in-process invocations.

Comment 2

[Andrew Halberstadt [:ahal]]

That's a good question, and you might have a point that it's not worth co-opting |mach watch|.

Probably the main benefit is not needing more than one file watcher process running. Another is only needing to have one file watcher installed. We already recommend watchman for fsmonitor and |mach watch|.

I sort of envision either people run |mach watch| (without arguments) locally, and that just watches all of the installed targets we implement by default. Or, commands like |mach doc| could dispatch to |mach watch| if the watcher isn't running already (|mach doc| actually already does file watching via the 'livereload' module, but we could consolidate it).

Comment 3

[Andrew Halberstadt [:ahal]]

Another use case for this would be rebuilding the local taskgraph for |mach try| whenever files under /taskcluster change.

Edit: Oops already suggested that in the description :p