Detecting the upstream repository isn't always possible. Using 'git merge-base'
seems to be a more reliable way of detecting outgoing files.
MozReview-Commit-ID: 3zOdTRIcggw
--HG--
extra : rebase_source : 56dfd16bbddca38195f6a833dc5696cf509f3fa8
In addition to help fix this bug, having the base revision will allow us
to download the most likely relevant artifacts from CI. For example, in
|mach try| we can search for a 'full-taskgraph.json' artifact from the
most relevant decision task, even if not updated to the latest central.
The ability to find the base revision will also be needed when merging
tools/tryselect/vcs.py into mozversioncontrol.
MozReview-Commit-ID: 2WRRs4AoXcK
--HG--
extra : rebase_source : 28d759ffaece14dd260402fa730136288ab8111b
This also migrates the vcs.py test to mozversioncontrol and adds a new task for
it.
MozReview-Commit-ID: 9jTRkjNupVA
--HG--
extra : rebase_source : 400f27498e00ea45234ad7c951770b098e916b8e
Sometimes commands return non-zero even though everything is ok. For example,
'hg outgoing' returns 1 if there are no outgoing files. This adds a way for
specific function calls not to abort if something goes wrong. Instead, stderr
will be printed (if any) and an empty string is returned.
MozReview-Commit-ID: E089djeHrmr
--HG--
extra : rebase_source : be351f357705e09c3fe876cecefa7ddd9c48987e
This adds 'get_outgoing_files'. First it automatically attempts to find the
upstream remote the current change is based on, then returns all files changed
in the local branch.
If an upstream remote can't be detected, it raises MissingUpstreamRepo
MozReview-Commit-ID: 9zSB9EdwVU8
--HG--
extra : rebase_source : e352d6d471644ef9eda76b972b789d6b54449471
There's currently a function for getting added files (A) and modified files
(M). We'll also eventually need the ability to get deleted files (D) and any
combination of the above, e.g (AM). Rather than creating a new function for
each possible case, let's have a single function where you can pass in which
modifiers you are interested in. With this patch, if you want all modified and
added files, you can do:
get_changed_files('AM')
By default 'ADM' is used.
This also adds a 'mode' option for git. This allows consumers to return staged
files, unstaged files or both. The default ('unstaged') keeps the current
behaviour in tact.
MozReview-Commit-ID: 9IA1bxaJS80
--HG--
extra : rebase_source : 160f650220ca9a35b4b116bc9fa13f28d84419fa
This is generally useful functionality to have. A consume will be
introduced in an upcoming commit.
MozReview-Commit-ID: 4arTMfJSiEC
--HG--
extra : rebase_source : 4bcf70f58b57b79b8dcb7a6eed633e1c7e42aca3
And convert consumers to context managers because hglib requires that.
MozReview-Commit-ID: Ckf1yBYeUlm
--HG--
extra : rebase_source : 985220032bced1a7077fd9b04ca8ad6de822c887
Because hglib spawns a persistent process, we introduce a context
manager for Repository. It no-ops by default. On HgRepository it
controls the lifetime of the persistent hg process.
A helper method for running an hg command via hglib has been added.
We can't transition existing methods to hglib because hglib
requires a context manager, which no consumer is using yet.
MozReview-Commit-ID: 8z0fcGFeAm5
--HG--
extra : rebase_source : 1cbfe44a5aafe838c25bcde91cc1deaf5e7367de
Some callers already have a build config object. Let's not
make them call a function that imports buildconfig.
MozReview-Commit-ID: J22HhyVma9y
--HG--
extra : rebase_source : fe5151925aee76508d26a9368e7a2ebec7e23ddb
``print()`` has no business being in library code like this. It was
a holdover from this code being copied from bootstrap. So remove it.
While we're here, replace the generic exception with a specific one.
We don't want to be swallowing bugs via ``except Exception``.
MozReview-Commit-ID: 49goUstfPBz
--HG--
extra : rebase_source : a821159bd12a449ed1a0edf21a1f9eb29711ad95
And convert consumers to context managers because hglib requires that.
MozReview-Commit-ID: Ckf1yBYeUlm
--HG--
extra : rebase_source : e76b2690bd02bc6889dbe0f4524d61669ba82367
Because hglib spawns a persistent process, we introduce a context
manager for Repository. It no-ops by default. On HgRepository it
controls the lifetime of the persistent hg process.
A helper method for running an hg command via hglib has been added.
We can't transition existing methods to hglib because hglib
requires a context manager, which no consumer is using yet.
MozReview-Commit-ID: 8z0fcGFeAm5
--HG--
extra : rebase_source : 914322f3647fb29406a22203811ac8cc0ac82420
Some callers already have a build config object. Let's not
make them call a function that imports buildconfig.
MozReview-Commit-ID: J22HhyVma9y
--HG--
extra : rebase_source : fa013dc0d8f85d1767e5666107ea656a17d137a2
The Repository interface gains a new method to determine if a sparse
checkout is present. Mercurial's implementation is somewhat crude,
but it should work (Mercurial's sparse support is still experimental
and I only intend to support sparse checkout in Firefox CI until it
is less experimental). Git's always returns False (for now).
To prove it works and to expose the information more widely, we hook
it up to moz.configure. We do this by first implementing a function
that returns a Repository instance. Then we simply call a function on
it to resolve the sparse checkout flag.
MozReview-Commit-ID: AlsT5LdSPdZ
--HG--
extra : rebase_source : f1e9aaa7d15f11c7c5e8d268d4ad82468732103b
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
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
For reasons I can't explain, Windows builds are failing intermittently
because they are unable to locate the `hg` binary when running
some SpiderMonkey test processes. These processes use
mozversioncontrol.get_repository_from_env() to locate the
current repository.
We now store VCS info in configure. This makes it available to anything
running in a build system context.
This commit teaches mozversioncontrol.get_repository_from_env()
to import the "buildconfig" module to locate VCS info. If the module
can be imported, it is the sole source of VCS info. Otherwise, we
fall back to the existing detection mechanisms.
This should get rid of the intermittent failure. If it doesn't,
it is still a step in the right direction because it will allow
build system processes to consistently use a well-defined VCS
binary.
MozReview-Commit-ID: DMxXheJLRqH
--HG--
extra : rebase_source : a9c599934c8c08da1fbb92a9105f5c7cba0867b3
We're getting an intermittent failure running `hg manifest` in CI. I
have no clue why.
What I do know is that we now have the mozversioncontrol Python package
for containing utility code for interacting with version control. It is
slightly more robust and I'm willing to support it more than I am
check_utils.py.
This commit adds a new API to our abstract repository class to obtain the
files in the working directory by querying version control.
Since I suspect cwd was coming into play in automation, I've also
added a utility function to mozversioncontrol to attempt to find
a version control checkout from the current working directory. It
simply traces ancestor paths looking for a .hg or .git directory.
Finally, I've ported all callers of the now-deleted API to the new
one. The old code had some "../.." paths in it, meaning it only
worked when cwd was just right. Since we resolve the absolute path
to the checkout and store it on the repo object, I've updated the
code so it should work no matter what cwd is as long as a repo can
be found. I'm not 100% confident I found all consumers assuming cwd.
But it's a start.
I'm not 100% confident this will fix the intermittent issues in CI. But
at least we should get a better error message and at least we'll be
running less hacky code.
MozReview-Commit-ID: AmCraHXcTEX
--HG--
extra : rebase_source : 815ae369776577ad374333920fd645d412a55148
This command is useful for users who wish to perform something like the
following:
1. Add/remove a bunch of files;
2. Examine the additions/removals/modifications for interesting changes;
3. Reject the add/remove if it doesn't meet some set of conditions.
I wanted to be able to do some VCS interaction from a mach command, and we
didn't have anything suitable, so I tore up mozversioncontrol and replaced
it with a framework to hang new features off of. I've only implemented
the bits I need currently (get_modified_files and add_remove_files),
but it should be straightforward to add more functionality there.
This patch also adds a `repository` property to `MozbuildObject`, which will
return a `Repository` object for the topsrcdir to make using these helpers
even easier for `MozbuildObject`-derived classes.
MozReview-Commit-ID: Gw6Ixp1ltiN
--HG--
extra : rebase_source : e619d6642eb86c3f96e679ac22a3e561dfdbb56a
Running old extensions with newer versions of Mercurial may crash `hg`
due to the old extension accessing something or doing something that has
been changed in the new release.
To minimize the risk of this happening, we disable common 3rd party
extensions when cloning or pulling as part of `mach mercurial-setup`. We
don't want to disable everything because some extensions (like
remotenames) provide features the user may want enabled as part of the
clone/update. This leaves the door open for more failures. Hopefully
this approach is sufficient. We can always revisit later.
--HG--
extra : rebase_source : 92e7d8fe227f29fc64c0f69021bd731ba762faf3
`mercurial version` doesn't always print the version number. `mercurial
--version` does. Use the latter.
--HG--
extra : rebase_source : 6f3c305ce8b38599a60c01d9cee410b724bfc37f
extra : amend_source : 430a3cf66094a62fabee59dbf4a486d4392a8c47
We want to make it turnkey for people to use reviewboard. So, we add
reviewboard and related functionality to |mach mercurial-setup|.
Since the reviewboard extension only works in Mercurial 3.0 and newer,
we add some version detection for the Mercurial version. This should
have been done months ago. We now have it.
I also took the opportunity to inform |mach bootstrap| that Mercurial
2.x is no longer modern.
I also updated the messaging around mq to encourage fewer new users to
use it. You may find this controversial. People can always ignore the
message.
Finally, I also added a histedit prompt to the mix, since a lot of
people don't know about that and many find it useful.
I could have broken this into multiple patches. Meh.
--HG--
extra : rebase_source : d33f8abcabb6ad6511c2f9e202283d43613fafc4
extra : amend_source : 3a56bc4d49ee6200cbdd0e87b4f28489518fee79