The file failed to compile due to octal syntax and missing imports.
After this change, we get a run-time error, which is strictly better.
MozReview-Commit-ID: nY9A13Pt3E
--HG--
extra : source : ef477a048b575958be74287a2273830813b385f1
Our normal ubuntu 16.04 test image is suitable for hosting an Android x86
emulator with these minor updates: Install kvm and make sure /dev/kvm
rw permissions are open for everyone. Note that /dev/kvm is generally
only visible when running docker with --privileged; its permissions
cannot be modified in the Dockerfile, only at run-time: run-task is the
first opportunity.
download-and-compress isn't very complicated and should work on Python 3
with minimal effort. So let's switch it to use Python 3.
MozReview-Commit-ID: 9G1WfcbbKEY
--HG--
extra : rebase_source : 3a6bab06c8500a90413e8b7642a7bf7bdff04a46
python-zstandard 0.9 has an API that exposes a file object interface
for compression and decompression. This means we can remove our
stream wrapper in order to consume a zstandard compressed tar file.
MozReview-Commit-ID: DeWWKnigJVa
--HG--
extra : rebase_source : b510b9c7cf4471df835c755299a7842d13188b67
The latest python-zstandard uses a newer zstandard that is faster.
It also has wheels available, which means installation doesn't require
Python development headers, etc.
MozReview-Commit-ID: 5gRq81KYmX4
--HG--
extra : rebase_source : 96ccc64e9707c6b4815c1bfa5c1a98b9a428b387
Version 0.9.0 bundles a newer version of the zstandard library, which
is a little faster and has a few minor bug fixes (none that we were
likely hitting, however).
MozReview-Commit-ID: 9YgSZ0G41eg
--HG--
extra : rebase_source : 8f5a68323b1e1fe7e9f1dd1a92e132434972d21d
We want Python 3 available everywhere because it is 2018.
MozReview-Commit-ID: L3wufNXKdnp
--HG--
extra : rebase_source : c260923e3c13f8b28e30eaaf6e1bd38f79500052
Address Sanitizer builds use --disable-crashreporter so they don't have
symbols zip files to upload. Don't run symbol upload tasks for these builds.
MozReview-Commit-ID: GeQgRZF3m8t
--HG--
extra : rebase_source : 6ac59c5c96b5fb5ddbbe8c60af3a203d02ea9883
Mainly so searching "toolchain" + "gcc" yields something useful in the
taskgraph.
MozReview-Commit-ID: HWiT3AwwYQ2
--HG--
extra : rebase_source : b1ba0dfb4f99b6f8abe42506e8b37db68ed03590
Instead of having a special test-set for linux64-qr we can just use the
regular test set, and explicitly disable the individual tests that are
failing.
MozReview-Commit-ID: 8MUj1YdtOsH
--HG--
extra : rebase_source : 5b4398ccedd208c97fe2c58024d98bfdb759c932
Instead of having a special test-set for linux64-qr we can just use the
regular test set, and explicitly disable the individual tests that are
failing.
MozReview-Commit-ID: 8MUj1YdtOsH
--HG--
extra : rebase_source : 4d38dd3ea7a6934c84e57d6a20c7dc457f06c2da
Note in particular that tasks that were previously set to run on just
['mozilla-central', 'try'] will now also run on inbound and autoland, in
addition to mozilla-beta and other release branches. In some cases (e.g.
for talos tests) this might result in a significant increase in load on
CI infrastructure. For the tasks that were already running on ['trunk',
'try'] the extra load from the release branches should be relatively
small and will only take effect once 62 moves off nightly into beta.
MozReview-Commit-ID: 6sn9q6rCxOK
--HG--
extra : rebase_source : c228adf059a950aec3e311ae11915caf345e854f
Mainly so searching "toolchain" + "gcc" yields something useful in the
taskgraph.
MozReview-Commit-ID: HWiT3AwwYQ2
--HG--
extra : rebase_source : b1ba0dfb4f99b6f8abe42506e8b37db68ed03590
Summary:
In essence, we're allowing a new field in the task definition,
which is trusted over the one that's passed in with the config. This
wouldn't make much sense if it had a real date in, but allows us to
set an empty string for the kind that needs it
Reviewers: bhearsum
Reviewed By: bhearsum
Bug #: 1458854
Differential Revision: https://phabricator.services.mozilla.com/D1214
--HG--
extra : rebase_source : 82145a94fa91957ffe57112a1c0d327d99e32b23
This Dockerfile downloads non-deterministic remote content (by cloning a
Git repo) and then executes code from it. Part of that code is
executing Python package installs.
Since this Docker image was generated, it appears the remote code
requires new build dependencies. This commit adds those package
dependencies.
Not having deterministic Docker image builds is a bug. I'll file a
follow-up so we pin the Git commit used for building so this type
of failure doesn't occur again.
--HG--
extra : amend_source : 533a95abeb7cf7ddc9a1329549f5d294baf983f5
Volumes are a docker-worker concept. They shouldn't be encountered on
Windows, which uses generic-worker.
MozReview-Commit-ID: KUdSxVHVJQ
--HG--
extra : rebase_source : ff54131d471ae2ae2465b11ca5ba6e787f5d11de
main() is quite long. And the control flow will become more complicated
as we support Windows.
Let's move the bulk of the cache configuration code into a standalone
function so main() is less cluttered.
MozReview-Commit-ID: xredCubr1E
--HG--
extra : rebase_source : 385fe6fe9e083cf585edc922b1fa26355d580c02
The code for cache and volume normalization makes assumptions that uid
and gid are defined. They are not defined if not running as root and
Python would crash in these code paths.
So, presumably this means that all tasks using run-task are running as
root. Let's codify that requirement.
This requirement is arbitrary. But let's not scope bloat run-task to
support scenarios until we need them.
MozReview-Commit-ID: 2uW4OSovzWi
--HG--
extra : rebase_source : 56ced8ecbd0eef3a55dc68413f4eab7601756cc0
I want to make run-task work on Windows. The script is currently very
POSIX oriented, as it assumes the existence of the grp and pwd modules,
that user IDs are numeric, and that system calls like setresgid() and
setresuid() are available, etc.
This commit starts to make some of the POSIX-centric code conditional
on running on POSIX.
Code for uid/gid extraction has been moved to its own function. Some
error messages were tweaked slightly as part of the move. Otherwise,
the changes should be pretty straightforward.
There are still other parts of this file that won't work on e.g.
Windows. But this gets us a big step closer.
MozReview-Commit-ID: HNyytKcBbBo
--HG--
extra : rebase_source : 01d653c801865e36e562a8de4c9e6d6962498f19
In preparation for making it usable on Windows, after which point
having it in a directory with "docker" in it doesn't make much sense.
MozReview-Commit-ID: Hgu0buFyJwF
--HG--
rename : taskcluster/docker/recipes/run-task => taskcluster/scripts/run-task
extra : rebase_source : 3c0b502d28b5aad54bd04069efbfda88e25bbb20
Summary: Now with correct phabricator usernames
Reviewers: aki
Reviewed By: aki
Bug #: 1458855
Differential Revision: https://phabricator.services.mozilla.com/D1133
--HG--
extra : rebase_source : fd8aa5de1c1aaedacbbad53fa692e6c3132a0a94
The python3-minimal package provides /usr/bin/python3 on Debian.
This commit installs this package so a `python3` executable is
provided.
This required backporting the package to wheezy. The final patch
is trivial. But I wasted a bit of time figuring out why `mk-build-deps`
wasn't working. It would no-op and exit 0 and then the build would
complain about missing dependencies!
glandium's theory is that the ":any" multiarch support on wheezy
isn't complete. Removing ":any" seems to make things "just work."
MozReview-Commit-ID: FBicpK4SmkQ
--HG--
extra : rebase_source : a28ce731024e8ed6a43fb30e2ed57da2abb50d0f
If we're not passed `release_partner_config` in the input, let's poll github for it in the action.
MozReview-Commit-ID: 2swx76vhTE5
--HG--
extra : rebase_source : d16c517348e506519bc6e6296ad7a0cb2f90527c
extra : source : 3ad2e53b051d48a54dfb1cf88b743ed4d9571ff6
We originally had this logic here, and called it from the `partner_repack` transform. This kept the config more hidden, but had the downsides of a) being difficult to test, and b) hitting the network during transforms, which we're trying to avoid.
We moved this code to release-runner3, and passed in the `release_partner_config` as input, and saved it as a parameter. Parameterizing the partner config means that we can refer to it easily throughout taskgraph generation and in local testing, and we don't have to hit the network during transforms. The downsides include potentially having to generate this config in multiple places (rr3, ship-it-v2, the partner hook), and risking hitting the 20k gpg cleartext character limit in the `ACTION_INPUT` environment variable.
Now I'm moving this code back into util.partners, but I'm calling it from the action, not from the transform. The action populates the `release_partner_config` parameter, so we can still access the config from anywhere in the taskgraph generation code, more easily test, and avoid hitting the network during transforms. It also means that release-runner3, ship-it-v2, and the partner hook can all use the partner config generation code from a single location, rather than having to duplicate it.
Hoping this is the last major change we need to make here for a while.
MozReview-Commit-ID: 8UmvmcAoZgD
--HG--
extra : rebase_source : 57464354ea294bec972d6ff44b8c9426b31fc644
extra : source : 21289762391e66c9330f5c6f93a417f8d608c6e9
A try push converting run-task to Python 3 seemed to complete without
error.
Since it is annoying writing code that needs to work on both Python
2 and 3, let's require Python 3 and remove code for supporting Python 2.
We implement a version check enforcing Python 3.5+. This is because
we're supposed to be standardizing on 3.5+ everywhere. I want to
prevent accidental usage of older Python 3 versions.
MozReview-Commit-ID: 4vATLZ6Si2e
--HG--
extra : rebase_source : d1450979e636387a5fdbd80ba19a92ec4fd31088
extra : histedit_source : 62910e29cc2fff0a1db0e9521cc58b200406d393
Python 3 is the future.
MozReview-Commit-ID: APuu4Q3mimj
--HG--
extra : rebase_source : 79839dc7f3ec130e467f1d0aa268bf3912cc1c8f
extra : histedit_source : 4be41658b5debaa6165228f60f09a9d1bf53ddbb
Mostly normalization of str and bytes. Python 3 is annoying for
systems level code where most things are bytes.
MozReview-Commit-ID: KpvZGegBkYn
--HG--
extra : rebase_source : aa50a6cd1337fe604015131b053234a2db642e57
extra : histedit_source : 8481b23bde4f408a59c623b8be43ee0611492afd
This required a lot of attention to bytes versus strings.
The hacks around handling process output are somewhat gross. Apparently
readline() doesn't work on bytes streams in Python 3?! So we install a
custom stream decoder so we can have nice things.
There are still some failures in run-task on Python 3. But we're a big
step closer.
MozReview-Commit-ID: 4FJlTn3q9Ai
--HG--
extra : rebase_source : 1a45b158fb625c7fd86701736b16da8df122218d
extra : histedit_source : f66fb22e86caf9b6b3cb301bedeab0b709685ef3
The file failed to compile due to octal syntax and missing imports.
After this change, we get a run-time error, which is strictly better.
MozReview-Commit-ID: nY9A13Pt3E
--HG--
extra : rebase_source : 074cbf7daaed820bd330b6850d28acd766b3801a
extra : histedit_source : e10c0a14f55148dd3e57a194d262ded41c038ee5
A try push converting run-task to Python 3 seemed to complete without
error.
Since it is annoying writing code that needs to work on both Python
2 and 3, let's require Python 3 and remove code for supporting Python 2.
We implement a version check enforcing Python 3.5+. This is because
we're supposed to be standardizing on 3.5+ everywhere. I want to
prevent accidental usage of older Python 3 versions.
MozReview-Commit-ID: 4vATLZ6Si2e
--HG--
extra : rebase_source : bbf3a0bd6cc881002d38c58eef64636c5efa6712
Mostly normalization of str and bytes. Python 3 is annoying for
systems level code where most things are bytes.
MozReview-Commit-ID: KpvZGegBkYn
--HG--
extra : rebase_source : 6bda98911cf32ce1bc3d651805b473aff18bf1f9
This required a lot of attention to bytes versus strings.
The hacks around handling process output are somewhat gross. Apparently
readline() doesn't work on bytes streams in Python 3?! So we install a
custom stream decoder so we can have nice things.
There are still some failures in run-task on Python 3. But we're a big
step closer.
MozReview-Commit-ID: 4FJlTn3q9Ai
--HG--
extra : rebase_source : 38d5626574d924c25e3fb4eecf29d379c2678e0d
The file failed to compile due to octal syntax and missing imports.
After this change, we get a run-time error, which is strictly better.
MozReview-Commit-ID: nY9A13Pt3E
--HG--
extra : rebase_source : b13d859ffaa2d10795312ff5a0f3ebbd5ca06835
Right now artifacts from previous tasks are left lying around. We should clean these up
in case a task accidentally uses an artifact from the wrong dependency.
Ideally we'd cache these properly based on the taskId they came from, but that can be
follow-up fodder.
MozReview-Commit-ID: HUgvNlqyFav
--HG--
extra : rebase_source : fb9c6723598223619993c2695fb588ead3325edb
Previously we would only generate upload-symbols tasks for nightly builds,
since we only want to upload symbols for builds we ship to users.
On try, developers may want to use the symbol server but very rarely want
to do nightly builds, so allow uploading symbols from any build type there.
MozReview-Commit-ID: IYs9mZii3DN
--HG--
extra : rebase_source : 15acb889510bb07ed3d29ea802997f11796dad9f
Tasks like upload-symbols that have a dependency on a build job want to
copy the treeherder.platform from the build job but it gets lost in
the task transform currently. This simply copies it into
an extra.treeherder-platform key to make life easier.
MozReview-Commit-ID: H4PtC4mvIYA
--HG--
extra : rebase_source : 5588bdadfcff8eb8f35935dc5c05dcde5658da83
filter_upload_symbols is a relic of task configurations that were written
before we had a better handle on taskgraph generation. We should only be
uploading symbols for nightly builds anyway, so this is better served using
newer filtering methods.
upload-symbols tasks were specified to run on non-nightly build types in the
kind.yml, but those were filtered out in filter_upload_symbols. I believe
these were simply an artifact of the initial upload-symbols implementation
happening before nightly builds were running in Taskcluster.
MozReview-Commit-ID: Je1NytrVPT8
--HG--
extra : rebase_source : a961c17d329af848fa7bb64c5186135d37dd412f
This is a follow up to 9c941daebe9fb3e79066ee4def16ed5ce0eb10a9
Differential Revision: https://phabricator.services.mozilla.com/D1140
--HG--
extra : rebase_source : 4c56ea683a7bcb3a80cd032e5491d3c13e891368
extra : source : 72e960bcc54751b15d144e0a5550c65649a2ad7d
We currently set GECKO_HEAD_REV to the revision being built, but the build
system already looks for MOZ_SOURCE_CHANGESET so set that as well. Additionally,
set MH_BRANCH for mozharness tasks on generic-worker to match docker-worker.
MozReview-Commit-ID: 52B3SSQpSwU
--HG--
extra : rebase_source : d65ca493764e6a5fbc7cca1d018b21cd6c82b6a0
extra : histedit_source : d7bd585e69fcc9b781550f89571250729882c8e8
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 72a4a4b691e93c77479c7e70647b0ca373862c51
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 7599913e547533f2f57b597ad0f238c6cd391c82
Previously, we installed the latest version of pip and virtualenv.
This commit pins the pip and virtualenv version so we install known
working versions (pip 10 breaks the image build for some reason).
MozReview-Commit-ID: hOAMencdcr
--HG--
extra : rebase_source : 2cb44c2ef55e29c55cf3d1b354e90d6fb5414cce
This merely extends the logic involved in shipping language packs to AMO. All devedition language packs will be shipped as 'unlisted' for now, meaning that there is no extra AMO work involved. The extension ID is taken from the langpack itself.
Differential Revision: https://phabricator.services.mozilla.com/D1104
--HG--
extra : rebase_source : a6fcc953c79531377540216343e9d0037a2879d6
The previous definitions are split across to files, but the task are complex
enough to warrant it.
Differential Revision: https://phabricator.services.mozilla.com/D1054
--HG--
extra : rebase_source : 2dd8b5330bfc835c23534037aa96370103248743
This commit adds CI tasks to perform "plain" builds. These builds use
the same toolchains used by official builds. But that's about it. The
mozconfig changes are minimal and only set up paths to toolchain
artifacts. sccache is not used.
The main goal of these builds is to have a "reference" build that
matches an out-of-the-box build environment as much as possible. We want
this mainly so we have timing and behavior information that matches what
developers are doing.
The Windows/generic Taskcluster worker doesn't like it when you specify
an artifact directory that doesn't exist. So we needed to add a
mozharness step to ensure UPLOAD_PATH exists to prevent those tasks from
erroring.
I'm not super thrilled about using mozharness here. We definitely don't
really need mozharness. But the main thing it is providing that we care
about is the Perfherder metrics data. I don't feel like scope bloating
to move that out of mozharness at this time.
I only implemented Linux64 and Windows64 because I'm not convinced
coverage on 32-bit build variations is useful. Tasks only run on trunk
because they are informational only and we don't need to waste resources
running these on release repos and on Try. They are tier 2 because they
aren't critical to shipping Firefox.
MozReview-Commit-ID: Gl6hGYbFX9b
--HG--
extra : rebase_source : 05360d2f6e5dbfed5543726a1be4b0e5d00e0b3d
Since it is run with `mach python`, it uses the environment defined by
`build/virtualenv_packages.txt`. Thus, we don't need to create a separate
virtualenv.
Differential Revision: https://phabricator.services.mozilla.com/D1015
--HG--
extra : rebase_source : 023095f82d7219a10dffb3579276c5285db37cfc
extra : source : a2999a5b9b7aa08a7c5c2ba6384724853d14b9c5
Sends 'in the candidates directory', 'pushed to cdntest', etc emails only when the underlying dummy tasks succeed, avoiding false messages when graphs are cancelled or the dummy job fails for infrastructure reasons.
Also sets the body of the email to be the same string as the subject, as we used to do, to avoid unnecessary information about the dummy task.
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
This option shouldn't be used for local builds (see bug 1294157). Set
the option from the crate's taskcluster script instead, so that it's
used only for automated builds.
--HG--
extra : rebase_source : 94b398a0f1fac60094269d755735c426ecc63e17
Previously, we had a single mac signing task that signed all mac locales and subpartners in a single signing task. This task required us to bump the signing task timeout. Chunking gives us a speed boost and a bit more resiliency if a single signing task fails - we don't have to re-sign everything, only the tasks that fail.
MozReview-Commit-ID: 4vPZE1vzZoQ
--HG--
extra : rebase_source : 320e9b51061b57d65d08aed1e621983e911c7b6d
extra : source : 00c8d34184b954d259c04459da916bda8baaca78
Because the transforms are generators, we actually call them from the bottom up. The previous transforms don't get called until the `for task in tasks:` or `for job in jobs:` in the following transform.
Moving the `check_if_partners_enabled` transform to the end means we never try to access `config.params['release_partner_config'].values()` in `add_command_arguments` when `release_partner_config` is None. Otherwise, we hit errors when we run taskgraph-gen.py.
MozReview-Commit-ID: Ho2odPL9FxS
--HG--
extra : rebase_source : 51406b39c358ff99690e073920a2e3f66cb39c83
extra : source : 02136f9beec0726098d9263f84f46244bd454b9f
Now that 28db2c96ac69 has been uplifted, get parameters from the new index paths.
--HG--
extra : rebase_source : 17166c55ad85ee153196e1797fe027dc6895beb2
The decision task is used for everything built as part of a push (for
mozilla-central, this is firefox, devedition and fennec, as well as tasks that
aren't strictly part of any product). Thus, having `firefox` encoded as part of
the decision task doesn't make sense.
This changes the route from
index.gecko.v2.${repository.project}.latest.firefox.decision
to
index.gecko.v2.${repository.project}.latest.taskgraph.decision
while leaving the latter for backwards compatability with tools that expect it.
Differential Revision: https://phabricator.services.mozilla.com/D996
--HG--
extra : rebase_source : c4c4691bb4633225e5e37b21982b916f76353e27
extra : source : 6ef1607a3e63250eefbda5333d61fd338c23311d
This will allow mozharness configs to be specified exclusively in the taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D1017
--HG--
extra : rebase_source : a3a9b6cc9d1004c4bd396fccc3e4354a7316651d
extra : source : 10acd193df92b7c495789dc24157b85f116ade5e
On ESR[60] stub installer isn't designed to work, and we expect most users of esr will have no use for a stub installer. However this poses some problems where the taskgraph assumes that any Nightly generates a stub installer and thus it should be available along the way.
The patch hardcodes the list of branches that do not need a stub installer, though we'll want to clean up this specification in some way, as Thunderbird will likely need it to be cleaner and we may want on-change builds to use this logic (e.g. for on-change l10n).
Differential Revision: https://phabricator.services.mozilla.com/D1082
--HG--
extra : source : 2f091908b8839650961c3968b6beee1dd8d1084b
This adds repackage-signing on mac and linux, depending on repackage and the chunking-dummy kinds respectively, and repackage-signing is extended to create gpg signatures. The signing_dependencies are no longer added because the beetmover_repackage_partner.py transform is going to set that up manually, and it avoids duplicate targets which the schema blocks.
Beetmover can depend now on repackage-signing for all platforms, and no longer has any indirect dependencies to worry about, but does need to know about copying the .asc files as upstream artifacts.
MozReview-Commit-ID: JcIdXQ2B7Rg
--HG--
extra : rebase_source : d05f1092b72e4241ff2f40b286cbe0f8af94ea67
The big win comes from removing the APT lists. We also reduce the
number of layers while we're here.
This makes the image 162 MB instead of 202 MB.
MozReview-Commit-ID: K2ic4zcr31j
--HG--
extra : rebase_source : afda144f1a1319971842642b58460de169e245fa
Instead of downloading the build artifacts (rather hackily) in moztest.fixtures, this now happens
directly in the taskgraph module via the run-task script.
For now extraction and setup happens in the task's command key. It might be a good idea to figure
out a syntax to tell run-task to do this extraction, e.g something like:
run:
using-artifacts:
build:
target.tar.bz2:
extract: true
path: /home/worker/build
name: firefox
But for now I wanted to avoid this extra complexity, so maybe it could be done in a follow-up.
MozReview-Commit-ID: KOhFFpFdP7Y
--HG--
extra : rebase_source : dcea36661fa9c6442c76c850ccc67f8f6d924fda
This adds a 'use-artifacts' key to the run_task schema. Tasks can specify artifacts to download like this:
run:
using: run-task
use_artifacts:
build:
- target.tar.bz2
- target.common.tests.zip
- target.mochitest.tests.zip
This will cause the run-task script to download those three artifacts from the task's 'build' dependency.
If the task doesn't have a 'build' dependency, taskgraph generation will error. The artifacts will be
downloaded into $USE_ARTIFACT_PATH. It is up to the task to do whatever extracting/setup may be required.
E.g this setup could go in the task's command.
At this time, only 'run-task' tasks using docker-worker are supported.
MozReview-Commit-ID: 3f02oCys62i
--HG--
extra : rebase_source : e8a85040e45042b537d4119334c4a8b7280b295c
This changes the default to opening a livereload webserver after doc generation
(as opposed to opening the index file). Any changes to the specified path will
result in a rebuild and refresh of the browser.
For example, if you run:
./mach doc tools/lint
The linting docs will be built, served and opened in a browser. Modifying any
file under 'tools/lint/docs' will refresh the browser with your changes.
To disable this behaviour and simply open the index file, you can pass in
'--no-serve'. The '--no-open' flag will continue to work (both with http and
the file system).
One caveat to this patch is that when generating the root docs (by running
|mach doc|), we don't watch all possible doc paths (just the root one under
'tools/docs/'). This will probably be fixed in the follow-up bug 1454640.
MozReview-Commit-ID: FQecuePM0zZ
--HG--
extra : rebase_source : 3240402d7505e99a4f64dada309b1baec78306e1
Summary: A space was needed to make the code block show up
Reviewers: bhearsum
Reviewed By: bhearsum
Bug #: 1355482
Differential Revision: https://phabricator.services.mozilla.com/D957
--HG--
extra : rebase_source : 58c163102ddfd9982a98c0bc2ef9967fbf883d15
Summary:
Disable just the buildbot version of the periodic file updates in the file_update action.
Removing the code will happen later.
Reviewers: Callek
Reviewed By: Callek
Bug #: 1453616
Differential Revision: https://phabricator.services.mozilla.com/D921
--HG--
extra : rebase_source : 929ac46305f72ef0355f040243270e2f1f032de3
Gregory Szorc
Tom Prince
Steve Fink
Margareta Eliza Balazs
Chris AtLee
Kartikaya Gupta
Dorel Luca
Geoff Brown
Andi-Bogdan Postelnicu
Ted Mielczarek
Maja Frydrychowicz
Narcis Beleuzu
Brindusan Cristian
Simon Fraser
Bogdan Tara
Sylvestre Ledru
Tom Ritter
Csoregi Natalia
Marco Castelluccio
Cosmin Sabou
Joel Maher
Andreea Pavel
Coroiu Cristina
Aki Sasaki
Rob Wood
Ciure Andrei
Andrew Halberstadt
Ben Hearsum
Mihai Tabara
Justin Wood
Johan Lorenzo
Dave Hunt
Nick Thomas
Gurzau Raul
Rail Aliiev
Dustin J. Mitchell
Hector Zhao
Kris Maglione
Robin Templeton
Chris Manchester
Mathieu Leplatre
shindli