This should make it easier for a user to troubleshoot the problem,
instead of trying to decipher a subsequent exception from a function
call being attempted on the `None` returned by this function.
Differential Revision: https://phabricator.services.mozilla.com/D200496
While this message was sometimes useful to help troubleshoot for end
users, it's causing issues parsing `stdout` (since it can't use the mach
logging infrastructure due to being too early in the startup). We also
can't use `stderr` since some mozharness scripts treat any `stderr`
output as a full error.
Differential Revision: https://phabricator.services.mozilla.com/D198451
It's not technically an error, but we can't make it debug level output
since the mach logging isn't available this early on startup. There's
precedent for using `stderr` output elsewhere in `site.py`, though it
usually precedes an exception being raised.
Differential Revision: https://phabricator.services.mozilla.com/D198307
If this is not done, the next person to vendor will also make all of the changes in this commit, which is unnecessary noise.
Differential Revision: https://phabricator.services.mozilla.com/D183450
I wasn't able to modify `sys.argv[1]` with the `suggested_command` and have
it propagate to `dispatcher.py`, so the code still has to run in both
places, otherwise there's crashes for trying to access invalid command
handlers.
Differential Revision: https://phabricator.services.mozilla.com/D194599
If this is not done, the next person to vendor will also make all of the changes in this commit, which is unnecessary noise.
Differential Revision: https://phabricator.services.mozilla.com/D183450
Takes use counter definitions and generates a use_counter_metrics.yaml with
`counter` metric definitions for each use counter and denominator.
Total use counters at time of writing: 2271 (excludes denominators)
Differential Revision: https://phabricator.services.mozilla.com/D193246
Aliased commands have not loaded the virtualenv associated with a
command/subcommand since bug 1695312. It has been defaulting to the
`common` virtualenv, which worked most of the time since most commands
use `common` and it also contains a large share of our dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D192376
Takes use counter definitions and generates a use_counter_metrics.yaml with
`counter` metric definitions for each use counter and denominator.
Total use counters at time of writing: 2271 (excludes denominators)
Differential Revision: https://phabricator.services.mozilla.com/D193246
Takes use counter definitions and generates a use_counter_metrics.yaml with
`counter` metric definitions for each use counter and denominator.
Total use counters at time of writing: 2271 (excludes denominators)
Differential Revision: https://phabricator.services.mozilla.com/D193246
Aliased commands have not loaded the virtualenv associated with a
command/subcommand since bug 1695312. It has been defaulting to the
`common` virtualenv, which worked most of the time since most commands
use `common` and it also contains a large share of our dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D192376
It was added in bug 1646794 and is now redundant with what was done more
generally in bug 1850647, although bug 1850647 doesn't keep track of all
arguments, but we've never made use of that information.
Differential Revision: https://phabricator.services.mozilla.com/D190854
Changes in Bug 1695312 made it so the actual command site is activated
much sooner, as such, at this point in the program execution, any of the
'Mach' sites can be active, so we should check against all of them.
In the past, the 'mach' site was the only one that could be active at
this time, so it was the only one that was needed to be checked for.
Differential Revision: https://phabricator.services.mozilla.com/D189290
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This wasn't really used anymore.
We are fetching the database from the server runtime in order to support
remote debugging correctly, where frontend CSS may be different from debuggee CSS.
Differential Revision: https://phabricator.services.mozilla.com/D187492
This just forces other command modules to be loaded in addition to the
'base' command. We need this so that decorators needed by the 'base'
command that are in another command module are ran during initialization
(eg: `@SettingsProvider`).
I thought about centralizing the `@SettingsProvider` decorators into one
module and always loading it, but they can depend on the
'command_handlers' in `Registrar`, so the modules they're currently in
have to be loaded for them to execute, so there wasn't a way around
this.
Differential Revision: https://phabricator.services.mozilla.com/D184852
This will make it so that if there was a potential subcommand, but it
was not a real subcommand, the base `command`'s site is still passed
through and activated.
Differential Revision: https://phabricator.services.mozilla.com/D184837
