.gecko_rev.yml
author Rob Lemley <rob@thunderbird.net>
Mon, 26 Aug 2019 21:20:54 -0400
changeset 35928 0bd1a3c3bee51d0643e1f3e9511876d27df182c1
parent 35913 2e34f364630f1f65724bb6e70616b95a041c47ea
child 35945 f34b5be061b01298b1d8d4cc974af13c5e69a29c
permissions -rw-r--r--
Bug 1507754 - Check source repositories and changesets during configure. r=darktrojan a=jorgk PACKAGERS: if you update application.ini, platform.ini, or source-repo.h in some way during your process, you might need to change something. Make sure that the source repositories for both Mozilla and Comm can be found during mach configure and abort if they cannot. For Taskcluster builds, there are various environment variables that can be relied upon. Local builds present a challenge. Chances are those variables are not set. I came up with a set of checks and keep trying until something works. For comm-* code: - Look for MOZ_SOURCE_REPO and MOZ_SOURCE_CHANGESET environment vars. This is counter-intuitive, but it's the current status-quo for Taskcluster builds. Those variables are set to the comm values. - Next, try use the Mercurial source checkout itself. Uses the same technique as Mozilla code does in build/variables.py. - Last, try to use a file named "sourcestamp.txt". That file is part of our source tar files that get built for releases. - Finally, if those MOZ_SOURCE environment variables were not set, set them. This is needed because old-configure will look for them and set buildconfig variables with them when it runs later during the configure process. - Additionally, set MOZ_COMM_SOURCE_REPO and MOZ_COMM_SOURCE_CHANGESET in buildconfig. Code in the comm- tree should prefer those values over the generic MOZ_SOURCE_* values that the Mozilla code will look at. For the Gecko/Mozilla source repository information, it's almost the same process. - Check for GECKO_SOURCE_REPO and GECKO_SOURCE_REV environment variables first. Taskcluster sets these based on comm/.gecko_rev.yml. - Next, try comm/.gecko_rev.yml itself. PyYAML is not required as the file is pretty simple to parse. Release builds are pinned to a specific revision hash, so we can use that. Builds from comm-central pin to "default" though, so next try running "hg id" in $topsrcdir to get the revision hash. - If for some reason there's no .gecko_rev.yml and it's not a Mercurial checkout, try the sourcestamp.txt file. - Set MOZ_GECKO_SOURCE_REPO and MOZ_GECKO_SOURCE_CHANGESET in buildconfig. mach configure should fail if any one of those values cannot be determined. The error message will suggest setting the environment variables; ideally that is not necessary.

---
GECKO_BASE_REPOSITORY: https://hg.mozilla.org/mozilla-unified
GECKO_HEAD_REPOSITORY: https://hg.mozilla.org/releases/mozilla-esr68
GECKO_HEAD_REF: THUNDERBIRD_68_VERBRANCH
GECKO_HEAD_REV: a3ab0641235427e02ccf8e0573b9e276d89cce43

### For comm-central
# GECKO_BASE_REPOSITORY: https://hg.mozilla.org/mozilla-unified
# GECKO_HEAD_REPOSITORY: https://hg.mozilla.org/mozilla-central
# GECKO_HEAD_REF: default
#
### For branches
# GECKO_BASE_REPOSITORY: https://hg.mozilla.org/mozilla-unified
# GECKO_HEAD_REPOSITORY: https://hg.mozilla.org/releases/mozilla-esr60
# GECKO_HEAD_REF: THUNDERBIRD_60_VERBRANCH
# GECKO_HEAD_REV: 6a830d12f15493a70b1192022c9985eba2139910
#
# Note about GECKO_HEAD_REV and GECKO_HEAD_REF:
# GECKO_HEAD_REF is a branch name or "default".
# GECKO_HEAD_REV is a revision hash. It cannot be a symbolic name like "default"
# or "THUNDERBIRD_60_VERBRANCH".
#
# comm-central will have GECKO_HEAD_REF defined as "default" but not
# GECKO_HEAD_REV. Release branches are pinned to a particular commit
# and set GECKO_HEAD_REV. They may also set GECKO_HEAD_REF when the pinned
# commit is in a branch within the repository, such as THUNDERBIRD_60_VERBRANCH.