Check the return code of write() to determine if the output line has actually been written completely; if not, write the remainder.
Tests suggest that incomplete writes are possible when the buffer exceeds a few thousand bytes. Very long log lines are unusual but this is important for cases like reftest failures where an encoded screenshot is dumped to the log.
Differential Revision: https://phabricator.services.mozilla.com/D48218
--HG--
extra : moz-landing-system : lando
For some tasks, the workdir known to the decision task doesn't actually match
the workdir used in the task, which makes MOZ_FETCHES_DIR wrong when the
decision task derives it from the workdir.
On other tasks, MOZ_FETCHES_DIR is set to a relative directory, which
may work in some places where MOZ_FETCHES_DIR is used, but not in
others, that happen to be executed from a different directory.
To solve both problems, we set MOZ_FETCHES_DIR as a relative directory
everywhere, and we make run-task normalize it to an absolute path
before executing the task.
Differential Revision: https://phabricator.services.mozilla.com/D39152
--HG--
extra : moz-landing-system : lando
For some tasks, the workdir known to the decision task doesn't actually match
the workdir used in the task, which makes MOZ_FETCHES_DIR wrong when the
decision task derives it from the workdir.
On other tasks, MOZ_FETCHES_DIR is set to a relative directory, which
may work in some places where MOZ_FETCHES_DIR is used, but not in
others, that happen to be executed from a different directory.
To solve both problems, we set MOZ_FETCHES_DIR as a relative directory
everywhere, and we make run-task normalize it to an absolute path
before executing the task.
Differential Revision: https://phabricator.services.mozilla.com/D39152
--HG--
extra : moz-landing-system : lando
Currently, all things running via run-task don't really care that the
current directory is set to /. However, on generic-worker, many things
assume the current directory is the task directory, which varies by
task, and wrapping them with run-task fails because it resets the
current directory.
Differential Revision: https://phabricator.services.mozilla.com/D28018
--HG--
extra : moz-landing-system : lando
With tasks able to access the hgmointernal config from a Taskcluster
secret, we can now add functionality to `run-task` to support checking
out from the private hg service. Here we add add a `resolve_checkout_url`
function which takes the base/head repository URLs and determines
whether we should clone from the public or private service, returning
the resolved URL. The function pulls down the secret and checks that
the region the task is executing in is in the set of supported regions.
Then we generate a random number and default to the public service if
the number is lower than our "rate". If all the above conditions are
met, we replace `hg.mozilla.org` with the resolved domain name for the
given region.
We add a call to this function to `collect_vcs_options`, and skip
resolving the private URL if we aren't performing a checkout from
within `run-task`.
Differential Revision: https://phabricator.services.mozilla.com/D25002
--HG--
extra : moz-landing-system : lando
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : source : f6413e576a2169855f766085704570c9fc851ee2
The shebang at the top of fetch-content doesn't work on macOS because
the path to python3 is not /usr/bin. Using /usr/bin/env doesn't work
properly on all platforms either so instead we invoke the script using
the currently running python executable.
Differential Revision: https://phabricator.services.mozilla.com/D19744
--HG--
extra : moz-landing-system : lando
We create a minimal wrapper function to call collect_vcs_options()
and vcs_checkout().
We could consolidate this logic into vcs_checkout(). But I don't have
strong feelings about doing that.
Differential Revision: https://phabricator.services.mozilla.com/D13821
--HG--
extra : moz-landing-system : lando
One step closer to making all state gathering and normalization in one
place.
Differential Revision: https://phabricator.services.mozilla.com/D13819
--HG--
extra : moz-landing-system : lando
This makes behavior consistent across all VCS checkouts. I'm still not
a fan of using environment variables here. But at least this gets us
1 step closer to being able to plug alternate logic in without having
to update use of environment variables outside a single function.
Differential Revision: https://phabricator.services.mozilla.com/D13816
--HG--
extra : moz-landing-system : lando
We currently manage VCS checkout arguments as one-offs for each
project. This isn't scalable and results in a bit of copy-pasta.
Let's make the VCS checkout arguments generic so we can have the
same control for all repositories.
This commit focuses on consolidating the existing argument parser
code. It stops short of further unification, which will be done in
subsequent commits.
Differential Revision: https://phabricator.services.mozilla.com/D13815
--HG--
extra : moz-landing-system : lando
This code was used by mozharness jobs to check out the tools repo.
However, those jobs aren't actually using the repository.
Differential Revision: https://phabricator.services.mozilla.com/D13855
--HG--
extra : moz-landing-system : lando
We have multiple source checkouts. --sparse-profile is ambiguous
as to which one it could refer to. Let's rename the argument so it
is prefixed with the repo/project we are checking out.
Differential Revision: https://phabricator.services.mozilla.com/D13814
--HG--
extra : moz-landing-system : lando
We now have multiple things we may check out. "vcs" meaning "gecko"
is not obvious. Let's change the terminology to be more specific.
Differential Revision: https://phabricator.services.mozilla.com/D13813
--HG--
extra : moz-landing-system : lando
We create a minimal wrapper function to call collect_vcs_options()
and vcs_checkout().
We could consolidate this logic into vcs_checkout(). But I don't have
strong feelings about doing that.
Differential Revision: https://phabricator.services.mozilla.com/D13821
--HG--
extra : moz-landing-system : lando
One step closer to making all state gathering and normalization in one
place.
Differential Revision: https://phabricator.services.mozilla.com/D13819
--HG--
extra : moz-landing-system : lando
This makes behavior consistent across all VCS checkouts. I'm still not
a fan of using environment variables here. But at least this gets us
1 step closer to being able to plug alternate logic in without having
to update use of environment variables outside a single function.
Differential Revision: https://phabricator.services.mozilla.com/D13816
--HG--
extra : moz-landing-system : lando
We currently manage VCS checkout arguments as one-offs for each
project. This isn't scalable and results in a bit of copy-pasta.
Let's make the VCS checkout arguments generic so we can have the
same control for all repositories.
This commit focuses on consolidating the existing argument parser
code. It stops short of further unification, which will be done in
subsequent commits.
Differential Revision: https://phabricator.services.mozilla.com/D13815
--HG--
extra : moz-landing-system : lando
This code was used by mozharness jobs to check out the tools repo.
However, those jobs aren't actually using the repository.
Differential Revision: https://phabricator.services.mozilla.com/D13855
--HG--
extra : moz-landing-system : lando
We have multiple source checkouts. --sparse-profile is ambiguous
as to which one it could refer to. Let's rename the argument so it
is prefixed with the repo/project we are checking out.
Differential Revision: https://phabricator.services.mozilla.com/D13814
--HG--
extra : moz-landing-system : lando
We now have multiple things we may check out. "vcs" meaning "gecko"
is not obvious. Let's change the terminology to be more specific.
Differential Revision: https://phabricator.services.mozilla.com/D13813
--HG--
extra : moz-landing-system : lando
The functionality is no longer used. All CI should be pinned to a full
revision hash for determinism.
Differential Revision: https://phabricator.services.mozilla.com/D14166
--HG--
extra : moz-landing-system : lando
It is no longer used. We can remove it. A subsequent commit will remove
logic for handling symbolic revisions completely.
Differential Revision: https://phabricator.services.mozilla.com/D14165
--HG--
extra : moz-landing-system : lando
For historical consistency and consistency with index paths.
"env_prefix" is no longer used after this change, so it has been
removed.
Differential Revision: https://phabricator.services.mozilla.com/D13876
--HG--
extra : moz-landing-system : lando
We create a minimal wrapper function to call collect_vcs_options()
and vcs_checkout().
We could consolidate this logic into vcs_checkout(). But I don't have
strong feelings about doing that.
Differential Revision: https://phabricator.services.mozilla.com/D13821
--HG--
extra : moz-landing-system : lando
Having this consistently enforced in the checkout function seems
better than looking at environment variables. Also, I think the old
logic was wrong, as it only ran if we weren't doing a checkout!
Although there is a strong possibility that I introduced this bug
via refactoring in this series.
Differential Revision: https://phabricator.services.mozilla.com/D13820
--HG--
extra : moz-landing-system : lando
One step closer to making all state gathering and normalization in one
place.
Differential Revision: https://phabricator.services.mozilla.com/D13819
--HG--
extra : moz-landing-system : lando
This makes behavior consistent across all VCS checkouts. I'm still not
a fan of using environment variables here. But at least this gets us
1 step closer to being able to plug alternate logic in without having
to update use of environment variables outside a single function.
Differential Revision: https://phabricator.services.mozilla.com/D13816
--HG--
extra : moz-landing-system : lando
We currently manage VCS checkout arguments as one-offs for each
project. This isn't scalable and results in a bit of copy-pasta.
Let's make the VCS checkout arguments generic so we can have the
same control for all repositories.
This commit focuses on consolidating the existing argument parser
code. It stops short of further unification, which will be done in
subsequent commits.
Differential Revision: https://phabricator.services.mozilla.com/D13815
--HG--
extra : moz-landing-system : lando
We have multiple source checkouts. --sparse-profile is ambiguous
as to which one it could refer to. Let's rename the argument so it
is prefixed with the repo/project we are checking out.
Differential Revision: https://phabricator.services.mozilla.com/D13814
--HG--
extra : moz-landing-system : lando
We now have multiple things we may check out. "vcs" meaning "firefox"
is not obvious. Let's change the terminology to be more specific.
Differential Revision: https://phabricator.services.mozilla.com/D13813
--HG--
extra : moz-landing-system : lando
This enables Windows generic-worker based tasks to use the run-task script.
Differential Revision: https://phabricator.services.mozilla.com/D10758
--HG--
extra : moz-landing-system : lando
Geoff Brown
Mike Hommey
Tom Prince
shindli
Joel Maher
Connor Sheehan
Kartikaya Gupta
Dorel Luca
Gregory Szorc
Bogdan Tara
Andrew Halberstadt