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
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
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
