Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
The idea here is that if someone else reported a bug and it got fixed immediately, but you don't have the fix yet for whatever reason (e.g you haven't pulled to the latest `central` or whatever), then you'll see it here. I've chosen 15 days as the cutoff basically arbitrarily.
Differential Revision: https://phabricator.services.mozilla.com/D91062
Today we don't require that `mach` `CommandProvider`s subclass from any particular parent class and we're very lax about the requirements they must meet. While that's convenient in certain circumstances, it has some unfortunate implications for feature development.
Today the only requirements that we have for `CommandProvider`s are that they have an `__init__()` method that takes either 1 or 2 arguments, the second of which must be called `context` and is populated with the `mach` `CommandContext`. Again, while this flexibility is occasionally convenient, it is limiting. As we add features to `mach`, having a better idea what the shape of our `CommandProvider`s are and how we can instantiate them and use them is increasingly important, and this gives us additional control when having `mach` configure `CommandProvider`s based on data that is only available at the `mach` level. In particular, we plan to leverage this in bugs 985141 and 1654074.
Here we add validation to the `CommandProvider` decorator to ensure all classes inherit from `MachCommandBase`, update all `CommandProvider`s in-tree to inherit from `MachCommandBase`, and update source and test code accordingly.
Follow-up work: we now require (de facto) that the `context` be populated with a `topdir` attribute by the `populate_context_handler` function, since instantiating the `MachCommandBase` requires a `topdir` be provided. This is fine for now in the interest of keeping this patch reasonably sized, but some additional refactoring could make this cleaner.
Differential Revision: https://phabricator.services.mozilla.com/D86255
This adds support for invoking the |mach logspam {report|file|bisect}|
commands. The core logic from the pypi base command is reused.
Differential Revision: https://phabricator.services.mozilla.com/D85493
With the addition of this change, a lone `mach busted file` will throw an error (since this should only ever be used by actual humans, and not in automation or anything, the backwards-compatibility breakage isn't a huge deal). Now it's expected to pass in `mach busted file $COMMAND`, where $COMMAND is the mach command that you were running when the error occurred, and we'll figure out which bugzilla component to file the bug against for you instead of directing it to `Firefox Build System :: General` regardless of whether the issue has *anything* to do with the build system. We preserve `mach busted file general` as a backup command that doesn't do any of this heavy logic.
Differential Revision: https://phabricator.services.mozilla.com/D77538
This commit re-implements `mach pastebin` for use with the new Mozilla
pastebin tool (paste.mozilla.org). As with the old implementation, the
tool supports passing a file for upload as well as reading content to
paste from stdin.
`dpaste` (the software that runs `paste.mo`) is supposed to support
sniffing the correct syntax highlighter from the given filename, but
this feature does not seem to work (both on `paste.mo` nor `dpaste.de`).
Instead we have a mapping of known filename extensions to known available
highlighters on `paste.mo`. `mach pastebin` will attempt to guess a
highlighter from the file extension or the basename of the file if none
is available.
Differential Revision: https://phabricator.services.mozilla.com/D42902
--HG--
extra : moz-landing-system : lando
For example, this is addressing the issue:
./mach clang-format -p ./mfbt/
MozReview-Commit-ID: Le8mPTOEfA7
--HG--
extra : rebase_source : ed196a2a86793d6601f590ce04744ebc7f3cd303
For example, this is addressing the issue:
./mach clang-format -p ./mfbt/
MozReview-Commit-ID: Le8mPTOEfA7
--HG--
extra : rebase_source : 87ca393854f1dfc4f3959e91677a4cbc6fb80287
This will remove the need to sniff class types. The 1 in-tree
consumer doing this has been converted.
MozReview-Commit-ID: I8cUa8J54VE
--HG--
extra : rebase_source : 4c24adaf7eb9d62678ac78604e819a7376d4073b
We've had 4 submissions in 2017. jgriffin and I agreed that it was a
failed experiment and we should either abandon it or figure out how
to increase participation. Since nobody is available to improve it,
I'm inclined to just delete it. If we want to bring it back, it is
always in version control.
MozReview-Commit-ID: AizkZxjQ8IJ
--HG--
extra : rebase_source : 0e29058cfc909fb51fc56fa9b46c0e0a6eef0bf9
The checking on the return of value of fetch/locate is not working as intended.
The code should be early returning, but the return value of fetch/locate is 1 in
failure cases, which will not trigger the early return. The return value has
been altered to None, which will trigger the early return.
MozReview-Commit-ID: FDCW6rbZI6T
--HG--
extra : rebase_source : 8b087174db268d7d6a0bb62e6537f82a3b15b28d
Currently the mach clang-format command is formating '-r tip^', which is
everything in the tip revision, plus changes. Often this does what you want,
but if you're using changeset evolution or history rewriting this doesn't work
so well. If you `hg up $rev` to some other revision with the intention of
clang-formating that revision, you don't get that revision formated when you
run clang-format. You get the lines touched by the changeset with the "tip"
bookmark formatted. We really want to have clang-format format '-r .^' which
means "the current revision in the working dir, plus any uncommited changes".
This results in the expected behaviour, and means clang-format can be used to
re-format commits which are work-in-progress and/or being evolved.
MozReview-Commit-ID: iv82HENxiA
--HG--
extra : rebase_source : a1d05472f499f5a68bcaab9ce260d60ecbca067d
This commit introduces the `mach rage` command. It opens a web browser
and loads a new tab with a short Google Form.
Google Forms appears to not have optional login where they capture login
info if available. So, we attempt to prepopulate the contact info
from version control or from the current login name. This field
is directly above the submit button, so it should be obvious enough
that people can clear it if they want to leave an anonymous response.
The alternative is we require a login to the Mozilla Google Apps
account. And that feels wrong.
r+ on this bug also constitutes r+ on the Google Form content.
MozReview-Commit-ID: HVAVVVva29T
--HG--
extra : rebase_source : d00aa424ffd42d8cd5d2d8a85aef8b3c24b59520
Ricky Stewart
Bogdan Tara
Dorel Luca
Eric Rahm
neil
Andrew Halberstadt
Dan Mosedale
Tilden Windsor
Connor Sheehan
Edwin Gao
Bobby Holley
Chris Manchester
Tom Ritter
Andi-Bogdan Postelnicu
Margareta Eliza Balazs
hrdktg
Sylvestre Ledru
Sebastian Hengst
Xavier ALT
Rok Garbas
Gregory Szorc
Prithviraj Pawar
Bryce Van Dyk
Chris Pearce
Ting-Yu Lin