https://wiki.mozilla.org/api.php?action=feedcontributions&user=Asasaki&feedformat=atomMozillaWiki - User contributions [en]2024-03-29T11:38:18ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=ReleaseEngineering:ProjectBranchPlanning&diff=1239551ReleaseEngineering:ProjectBranchPlanning2021-12-14T18:40:13Z<p>Asasaki: Deprecated</p>
<hr />
<div>Deprecated in favor of [https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectRepositories Disposable Project Branch]</div>Asasakihttps://wiki.mozilla.org/index.php?title=GitHub&diff=1229267GitHub2020-07-20T15:54:50Z<p>Asasaki: mozilla-extensions</p>
<hr />
<div>This page is specifically about [https://github.com/mozilla the "mozilla" organization on github]. There are several other github organizations you may be interested in, cf. the incomplete list [[#other_github|below]].<br />
<div id="contact"><br />
{| class="wikitable"<br />
|-<br />
! [[File:Red_question_mark.png|144px|Send us an email!|link=]] Do you have a GitHub administration question for an org?<br > See [[#other_github|table]] for contact info for each organization.<br />
|}<br />
<br />
== News ==<br />
* 2019-02-19 - Mozilla's Code of Conduct is required to be included in every repository, following [[/Repository Requirements|this procedure]].<br />
* 2018-03-29 - new [[/Repository Security|Guidelines for securing sensitive repositories]] published. These are good practices for any repository that does "releases", and some groups my require adherence on their repositories.<br />
<br />
== Recommendations and FAQ ==<br />
<br />
The actions below are specifically for the 'mozilla' organization on GitHub. Other organizations may have different or additional procedure. Please refer to the [[#other_github|other organizations]] table below for the proper service request address and contact information.<br />
<br />
=== Where should I ask additional questions? ===<br />
* Please use the '''[[#other_github|contact list]]''' to find the best address.<br />
* If the issue relates to the [https://github.com/Mozilla Mozilla] org, then you can send an email to '''{{emailentry|github-owners|mozilla.org|at=is}}''' and one of the volunteers will respond. <br />
* For other orgs, the volunteers in the [https://chat.mozilla.org/#/room/#github-admin:mozilla.org #github-admin] room on Matrix may be able to point you in the correct direction.<br />
<br />
=== How do I hook up a new GitHub Actions or 3rd party application to a repository in the mozilla org? ===<br />
{{note|There are now multiple 3rd party application types. "GitHub Apps" (nee integrations) are the new approach and preferred.|gotcha}}<br />
{{note|Some 3rd party apps use GitHub as an OAuth identity provider for their website (e.g. for a dashboard). An ''OAuth Application'' will block the installation process if the app is not already approved. The "Request access" block is what this section describes.|gotcha}}<br />
<br />
Each type has it's own installation and approval process. Please follow the instructions in the correct section below.<br />
<br />
==== GitHub Actions ====<br />
[https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions GitHub Actions] allow automation to be initiated by various repository events. However, GitHub Actions are only enabled on "modern" accounts. Many of the Mozilla orgs are "legacy" accounts (including 'mozilla'), so GitHub actions are not always available. Check with your organization owners if you have questions. <br />
<br />
{{note|GitHub Actions have not yet been evaluated for use on "sensitive repositories". Please work with your security team if you wish to utilize GitHub Actions on a sensitive repository.|gotcha}}<br />
<br />
==== GitHub Apps Installation & Approval Process ====<br />
<br />
GitHub Apps (formerly called "integrations") are "Installed" into either the entire organization, or into individual repositories. Each integration has a documented and granular access to repository resources. This is good.<br />
<br />
However, the GitHub App installation can only be done by an organization owner, who may have to do additional housekeeping. This is not so good, so please plan accordingly (you may need to coordinate with [[#contact|GitHub owners]]).<br />
<br />
* File a request using this [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE bug template]<br />
* Include answers to the questions prompted for in the above template. Additional notes:<br />
** ''Which repositories do you want to have access? (all or list)'' -- "All" will rarely be granted - every repository should have control over anything that can access their repository.<br />
** ''Are any of those repositories private?'' -- In general, OAuth apps will not be granted access to private repositories, as that grants access to ''all'' private repositories.<br />
** ''Provide link to vendor's description of permissions needed and why'' -- Hopefully they have this documented, or at least provide a screenshot of the authorization screen which lists the permissions. If not, we may ask you (the requestor) to engage with the app's support team to obtain the answers.<br />
** ''Provide the Install link for a GitHub app'' -- mandatory, as we can't install the app without it.<br />
<br />
* If you are not an "admin" for the repository, an "admin" will have to approve the request. Please set a "Need Info" on the appropriate repository admin.<br />
<br />
===== Initial Installation =====<br />
If this is the first time this GitHub App is being installed in the organization, a few extra checks and coordination are needed. An organization owner will need to perform these steps:<br />
* Determine if the GitHub App previously had an OAUTH version in use in the same org. (The simplest way is to see if the app is listed under the "Third-party Application" section of the organization settings page. ''Any mention'' -- including "declined" -- counts as "in use" for this purpose.)<br />
** If the OAuth app was in use, check the app installation documentation to see if there are any caveats. (We've only seen one app transition where there was an impact, but better safe than sorry.)<br />
** If there are caveats that apply, ask the requestor to contact all current repositories using the classic OAUTH application to coordinate, cc'ing [[#contact|GitHub owners]]. This task is non-trivial, you usually need to access the OAuth app's dashboard, and have knowledge of how the app works. ('''Do NOT''' authenticate to any OAuth app with your owner account.)<br />
* Install the GitHub app for "specific repositories", and enable the ones in the request.<br />
<br />
'''Please do not install GitHub apps with organization wide scope without first discussing with [[#contact|GitHub owners]].'''<br />
<br />
===== Additional Installations or Removals =====<br />
If the GitHub App has already been installed in the organization, the new repository simply needs to be added or removed from the list. An organization owner has to make this change. Please still [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE file a bug]. As before, a repository admin has to approve the request.<br />
<br />
If you're an org owner, you can [https://github.com/organizations/mozilla/settings/installations see what has already been installed].<br />
<br />
==== OAUTH (classic) Applications ====<br />
<br />
* Authorizing an application to work with GitHub utilizes the permissions your account has -- so, any repositories you have access to the application will have access to as well (including private ones). If you want to grant access to an application that no one else has used with the Mozilla organization yet you'll see a "Request access" button during the set up flow. You'll need to click that button to request approval. See below for an example:<br />
<br />
[[File:github_approval.png]]<br />
<br />
* In some cases, the application does not need to be "approved" to function correctly, as it has read only access to any public repository. (Some applications only want write access to help you configure the application first time.)<br />
<br />
* In other cases, the application does need write permission, and/or permission to read a private repository. In these cases, open a bug using [https://bugzilla.mozilla.org/enter_bug.cgi?cc=gene%40mozilla.com&comment=I%20want%20to%20use%20the%20NAME_HERE%20addon%20in%20ORG_NAME_HERE%20for%20the%20following%20reasons%3A%0D%0A%0D%0ABelow%20are%20my%20answers%20to%20your%20stock%20questions%3A%0D%0A%0D%0A%2A%2A%20Which%20repositories%20do%20you%20want%20to%20have%20access%3F%20%28all%20or%20list%29%0D%0A%0D%0A%2A%2A%20Are%20any%20of%20those%20repositories%20private%3F%0D%0A%0D%0A%2A%2A%20Provide%20link%20to%20vendor%27s%20description%20of%20permissions%20needed%20and%20why%0D%0A%0D%0A%2A%2A%20Provide%20the%20Install%20link%20for%20a%20GitHub%20app%0D%0A&component=Github%3A%20Administration&product=mozilla.org&short_desc=Assess%20use%20of%20external%20addon%20NAME_HERE%20in%20Mozilla%27s%20GitHub%20organization%20ORG_NAME_HERE this template].<br />
** Please be sure to have clicked the "Request Approval" link before submitting bug.<br />
* Include answers to these questions:<br />
** Provide link to vendor's description of permissions needed and why<br />
** Provide installation instructions (both may be needed):<br />
<br />
=== Reviewing owners and permissions ===<br />
As an owner or repository admin you're responsible for maintaining the list of people with access to your projects. Please be active and prudent about maintaining this list.<br />
<br />
=== Can I be an Owner of the Mozilla Organization? ===<br />
The Owners group on GitHub has complete administrative power and will be limited to a minimal number of people and reviewed regularly. If a person is an owner, they are expected to actively participate in the group and assist others as requested. Owners will be added as a need arises (for example, support in another timezone) as determined by the current owners.<br />
<br />
=== Can I be a Member of the Mozilla Organization? ===<br />
<div id="join"> </div><br />
==== Contributor Information ====<br />
Good news! You do not need to be a member of the Mozilla organization on GitHub before you can contribute to Mozilla!!!! We have several sites which can help you find the best fit for contribution:<br />
* General [https://www.mozilla.org/en-US/contribute/ volunteering options],<br />
* Or pick from [http://whatcanidoformozilla.org/ these areas],<br />
* Or jump right into [http://www.joshmatthews.net/bugsahoy/ fixing a bug].<br />
* If you're already a contributor (THANK YOU!) looking for a place to have your work recognized (even if not coding related), please see the [https://www.mozilla.org/credits/FAQ Credits FAQ] for inclusion in the [https://www.mozilla.org/credits/ credits].<br />
<br />
Once you're working on a project, the project leaders and/or team maintainers can help you get access to anything you need. Instructions for them are directly following.<br />
<br />
==== Team Maintainers & Project Leads ====<br />
<br />
Project owners and team maintainers may find the following information helpful when asking for access for a new team member:<br />
<br />
* We prefer the use of github teams when granting permissions to org members. (Collaborators have to be added individually.)<br />
* All members of the [https://github.com/mozilla/ Mozilla organization on github] agree to be bound by [https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/ Mozilla's Commit Access Requirements], and should follow the intent of the [https://www.mozilla.org/en-US/about/governance/policies/commit/access-policy/ Mozilla's Commit Access Policy] as much as practical. Of course, anyone interacting with Mozilla repositories agrees to [https://www.mozilla.org/en-US/about/governance/policies/participation/ Mozilla Community Participation Guidelines]<br />
** "Outside Collaborator": repository admins can grant outside collaborator to any GitHub account. "Outside Collaborator" is roughly analogous to "Level 1a" access to Mozilla-hosted repositories.<br />
** "Team Member": team maintainers can add GitHub users to a team, if they are already a member of the organization. If you are not yet a member of the organization, the ''team maintainer'' should [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=nobody%40mozilla.org&bug_ignored=0&bug_severity=normal&bug_status=NEW&bug_type=task&cf_fx_iteration=---&cf_fx_points=---&comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGitHub%23Team_Maintainers_.26_Project_Leads%2C%20and%20need%20help%20adding%20a%20contributor%20to%20the%20org%3A%0D%0A%0D%0AName%3A%20%0D%0AMozilla%20Email%3A%20%0D%0AGithub%20Profile%20link%3A%20%2AStaff%20%2A%2AMUST%2A%2A%20have%20their%20verified%20GitHub%20identity%20listed%20in%20their%20people.m.o%20entry%2A%0D%0AGithub%20Team%28s%29%20%2AREQUIRED%2A%3A%20%0D%0A%0D%0AIf%20this%20is%20not%20being%20requested%20by%20a%20team%20maintainer%2C%20please%20request%20their%20approval%20via%20need-info.&component=Github%3A%20Administration&contenttypemethod=list&contenttypeselection=text%2Fplain&defined_groups=1&filed_via=standard_form&flag_type-4=X&flag_type-607=X&flag_type-800=X&flag_type-803=X&flag_type-936=X&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Unspecified&priority=--&product=mozilla.org&rep_platform=Unspecified&target_milestone=---&version=other file a bug using this link] to add you to their team, as a form of vouching. "Team Member" is roughly analogous to "Level 2" or "Level 3", with the distinction being the content of the repositories managed by the team.<br />
<br />
To get access for a new Contributor, please have the ''team maintainer'' or ''repository admin'' [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=nobody%40mozilla.org&bug_ignored=0&bug_severity=normal&bug_status=NEW&bug_type=task&cf_fx_iteration=---&cf_fx_points=---&comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGitHub%23Team_Maintainers_.26_Project_Leads%2C%20and%20need%20help%20adding%20a%20contributor%20to%20the%20org%3A%0D%0A%0D%0AName%3A%20%0D%0AMozilla%20Email%3A%20%0D%0AGithub%20Profile%20link%3A%20%2AStaff%20%2A%2AMUST%2A%2A%20have%20their%20verified%20GitHub%20identity%20listed%20in%20their%20people.m.o%20entry%2A%0D%0AGithub%20Team%28s%29%20%2AREQUIRED%2A%3A%20%0D%0A%0D%0AIf%20this%20is%20not%20being%20requested%20by%20a%20team%20maintainer%2C%20please%20request%20their%20approval%20via%20need-info.&component=Github%3A%20Administration&contenttypemethod=list&contenttypeselection=text%2Fplain&defined_groups=1&filed_via=standard_form&flag_type-4=X&flag_type-607=X&flag_type-800=X&flag_type-803=X&flag_type-936=X&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Unspecified&priority=--&product=mozilla.org&rep_platform=Unspecified&target_milestone=---&version=other file a bug using this link], and fill in the details.<br />
<br />
'''Please Note:'''<br />
* All staff (folks with an entry in people.mozilla.org) '''MUST''' have their verified GitHub identity entered there.<br />
* We will cancel any invitation to the organization which is not accepted within 2 weeks.<br />
* All members of the Mozilla organization on GitHub '''MUST''' have [https://help.github.com/articles/about-two-factor-authentication/ 2FA enabled].<br />
* Automation accounts are also required to have 2FA enabled. Scripts should use [https://help.github.com/articles/creating-an-access-token-for-command-line-use/ access tokens] with minimum permissions to accomplish the task.<br />
<br />
=== Should I make a separate github organization or just create a repository in an existing one? ===<br />
This is a personal preference, in general. (Some product lines may have policies about source code locations.) If you have a large enough project or organization feel free. We suggest you use the strategies and recommendations here as a model to manage the details. Additional resources on establishing an organization are:<br />
* [https://mana.mozilla.org/wiki/display/POLICIES/Standard%3A+GitHub+repositories+and+organizations Mozilla Standards] <small>''login required''</small><br />
* [[/Repository Security|Guidelines for securing sensitive repositories]]<br />
* If you need any paid services, contact github owners for access to [https://github.com/mozilla/admin_for_mozilla_private/wiki/Billing-Notes Billing Notes]<br />
<br />
=== Forking vs Transferring ===<br />
'''Do not "fork" a repository into a Mozilla organization.''' Doing so gives ''every team in the org'' rights to it.<br />
<br />
If you have created a repo on your own account (for example, myuser/myrepo) and it should live under the Mozilla organization, here are the steps:<br />
<br />
# If you're not a member of any team, talk to an [[#contact|org admin]].<br />
# Under the repo admin, transfer ownership to the Mozilla organization. If you don't see this option, return to step 1.<br />
# Choose which teams should be given access. All chosen teams will have only 'read' access at this point.<br />
# [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=nobody%40mozilla.org&bug_file_loc=http%3A%2F%2F&bug_ignored=0&bug_severity=normal&bug_status=NEW&cc=gene%40mozilla.com&cf_fx_iteration=---&cf_fx_points=---&comment=I%20just%20transferred%20the%20NAME_HERE%20repository%20to%20the%20ORG_NAME_HERE%20organization%2C%20and%20thus%20no%20longer%20have%20admin%20access.%0D%0A%0D%0APlease%20enable%20admin%20access%20for%3A%0D%0A-%20the%20TEAM_NAME%20team%20%28preferred%29%2C%20or%0D%0A-%20just%20me%20--%20I%27ll%20take%20care%20of%20the%20rest&component=Github%3A%20Administration&contenttypemethod=list&contenttypeselection=text%2Fplain&defined_groups=1&flag_type-4=X&flag_type-607=X&flag_type-800=X&flag_type-803=X&form_name=enter_bug&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=Unspecified&priority=--&product=mozilla.org&rep_platform=Unspecified&short_desc=Admin%20access%20needed%20to%20transferred%20repository&target_milestone=---&version=other File a bug] to grant admin permissions to a team or yourself. {{note|As soon as you transfer, your repository will be in "limbo" (only you will have write access) due to a GitHub bug. Make arrangements in advance to have an owner available to process the bug.|gotcha}}<br />
# Fork the repo from Mozilla (mozilla/myrepo) back to your account (recreating myuser/myrepo). While the transferred repo becomes the root of the network on GitHub (e.g. all forks are now forks of mozilla/myrepo) other users may be pointing to your repo by URL. (Optional, github will redirect old URLs for transfers, but you probably want a local repo if you use the PR workflow.)<br />
<br />
=== Do I need to be an owner to create repositories? ===<br />
Not in the 'mozilla' organization. If you are a member, you can create a repository. Other organizations may restrict repository creation. However, it's preferred that you create repositories in the context of a team. Teams are created [https://github.com/orgs/mozilla/teams here], if necessary. Once you have created a repo, you can configure it to give rights to members of particular teams.<br />
<br />
{{note|Remember that all repositories must comply with the [[GitHub/Repository Requirements]].|reminder}}<br />
<br />
The 'mozilla' organziation does have a limited number of private repositories available. These are reserved for repositories containing [[Security/Data_Classification|non-public data]], or other business reason. Please request private repositories using this [https://bugzilla.mozilla.org/enter_bug.cgi?bug_type=task&comment=I%27ve%20read%20all%20of%20the%20%5Brepository%20creation%5D%5B1%5D%20section%2C%20and%20want%20to%20request%20a%20private%20repository.%20I%27ve%20filled%20in%20all%20the%20required%20fields.%0D%0A%0D%0AName%20of%20Repository%3A%20%20REQUIRED%0D%0ALink%20to%20your%20people.m.o%20entry%20with%20verified%20GitHub%20login%3A%20REQUIRED%0D%0A%0D%0A%5BData%20Classification%5D%5B2%5D%20of%20data%20in%20repo%3A%20REQUIRED%0D%0AOther%20business%20justification%20for%20private%20repo%3A%0D%0AWhen%20can%20the%20repository%20be%20made%20public%3F%20REQUIRED%0D%0A%0D%0A%5B1%5D%3A%20https%3A%2F%2Fwiki.mozilla.org%2FGitHub%23Do_I_need_to_be_an_owner_to_create_repositories.3F%0D%0A%5B2%5D%3A%20https%3A%2F%2Fwiki.mozilla.org%2FSecurity%2FData_Classification%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org&short_desc=Request%20for%20a%20Private%20Repository%20in%20the%20mozilla%20GitHub%20organization&groups=mozilla-employee-confidential Bugzilla template]. Be sure to answer all questions marked 'REQUIRED' in the form.<br />
<br />
As the creator, you will automatically have "admin" permissions on the repository. Repository Admins are responsible for the security settings of the repository. This includes approving (or not) requests for GitHub Apps to be added to the app.<br />
<br />
Please review all the settings for your new repository, and disable features you will not be using. The default values can change, and new services added, so specific guidance can't be given. But do you really need that wiki? Or the project board? You can always enable them later if you decide you need them.<br />
<br />
=== We have sensitive code or data in this repository - any extra steps I should take? ===<br />
Yes. Even if your repository is private, there are steps you can take to ensure you know if something has changed. See the [[GitHub/Repository Security]] page for additional information and a checklist.<br />
<br />
=== We're done with this project - what should we do with the repository? ===<br />
<br />
That is really up to the team. However, if you have forks or other active user participation, it's a good idea to be clear about the status of Mozilla's commitment to the project. Your options include:<br />
* Delete the repo (obviously the worst alternative).<br />
* Add the [http://unmaintained.tech/ Unmaintained] badge to the readme<br />
* Archive the repository, using [https://help.github.com/articles/about-archiving-repositories/ GitHub's suggestions].<br />
<br />
'''PLEASE''' make sure the repository is clearly licensed before leaving it. Without a license, many other folks can not build upon your work.<br />
<br />
=== Are there requirements for when or how I should create a new team? ===<br />
No. When requirements were proposed they all seemed too rigid and time consuming. Instead we recommend staying flexible and using good naming and documentation for projects (similar to naming CSS classes or variables).<br />
<br />
On large teams we recommend you separate teams for read/write and repository administration.<br />
<br />
<div id="other_github"></div><br />
=== Is "mozilla" the only github "organization" related to Mozilla? ===<br />
No, there are plenty of Mozilla-related "organizations" on github. As a rule of thumb, initiatives that create a large number of sub-repositories will create their own "organization". Here is a (probably incomplete) list of them:<br />
<div style="display: flex; flex-flow: row wrap; width: 100%;"><br />
<div style="order: 1; flex-grow: 3; margin: 0.5em; border: 0.1em solid darkgreen; padding: 0.5em; background-color: palegreen; min-width: auto; text-align: center;"><br />
<big>'''NOTE:''' All GitHub Organizations in this section are subject to the [[GitHub/Repository_Requirements|Repository Requirements]].</big><br />
</div><br />
</div><br />
{| class="wikitable sortable" <br />
|-<br />
! Organization !! Description !! Contact Owner !! Service Requests<br />
|-<br />
| [https://github.com/mozilla mozilla] || Mozilla main organization || Matrix [https://chat.mozilla.org/#/room/#github-admin:mozilla.org #github-admin:mozilla.org]; Email {{emailentry|github-owners|mozilla.org|at=is}} || Please check above for a more specific link, otherwise use [https://bugzilla.mozilla.org/enter_bug.cgi?comment=I%27ve%20read%20https%3A%2F%2Fwiki.mozilla.org%2FGithub%2C%20and%20need%20help%20with%20the%20following.%0D%0A%0D%0A&component=Github%3A%20Administration&form_name=enter_bug&product=mozilla.org& mozilla.org :: Github: Administration]<br />
|-<br />
| [https://github.com/mozilla-it mozilla-it] || Mozilla IT's repositories || Slack/🔒it-all||<br />
|-<br />
|[https://github.com/mozillabrasil mozillabrasil] || Mozilla Brazil|| ?<br />
|-<br />
| [https://github.com/bugzilla bugzilla] || Bugzilla (the product, not bugzilla.mozilla.org) || #bugzilla||<br />
|- <br />
| [https://github.com/drumbeat-badge-sprint drumbeat-badge-sprint] || Drumbeat Badge Lab || ?||<br />
|-<br />
| [https://github.com/hackasaurus hackasaurus] || Hackasaurus || ?||<br />
|-<br />
| [https://github.com/jetpack-labs jetpack-labs] || Jetpack Labs || ?||<br />
|-<br />
| [https://github.com/mdn mdn] || Mozilla Developer Network || [https://github.com/jwhitlock John Whitlock]||<br />
|-<br />
| [https://github.com/mozbrick mozbrick] || Mozilla Brick (web components library) || ?||<br />
|-<br />
| [https://github.com/mozilla-appmaker mozilla-appmaker] || Mozilla Appmaker || ?||<br />
|-<br />
| [https://github.com/mozilla-b2g mozilla-b2g] || Mozilla Boot2Gecko / Firefox OS || ?||<br />
|-<br />
| [https://github.com/mozilla-bteam mozilla-bteam] || Bugzilla.Mozilla.org || #bteam||<br />
|-<br />
| [https://github.com/mozilla-cit mozilla-cit] || Mozilla Community Ops || {{Mozillians|tanner|Tanner Filip}} or {{Mozillians|yalam96|Yousef Alam}}||<br />
|-<br />
| [https://github.com/mozilla-comm mozilla-comm] || Calendaring and Messaging related projects || ?||<br />
|-<br />
| [https://github.com/mozilla-cordova mozilla-cordova] || Firefox OS Support for Apache Cordova || ?||<br />
|-<br />
| [https://github.com/mozilla-iam mozilla-iam] || Mozilla's identity and access management || kang||<br />
|-<br />
| [https://github.com/mozilla-iot mozilla-iot] || Mozilla's Internet of Things program || {{Mozillian|dbryant|David Bryant}}, {{Mozillian|bfrancis|Ben Francis}}||<br />
|-<br />
| [https://github.com/mozilla-lockbox mozilla-lockbox] || Mozilla Lockbox iOS, Android, desktop extension || [https://github.com/orgs/mozilla-lockbox/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-lockbox owners]||<br />
|-<br />
| [https://github.com/mozilla-metrics mozilla-metrics] || Mozilla Metrics || ?||<br />
|-<br />
| [https://github.com/mozilla-platform-ops mozilla-platform-ops] || Mozilla Platform Operations || [[Platform_Operations]]||<br />
|-<br />
| [https://github.com/mozilla-raptor mozilla-raptor] || Mozilla Raptor / Firefox OS Performance || {{Mozillian|eliperelman|Eli Perelman}}, {{Mozillian|rwood|Rob Wood}}||<br />
|-<br />
| [https://github.com/mozilla-releng mozilla-releng] || Mozilla Release Engineering || #releng||<br />
|-<br />
| [https://github.com/mozilla-services mozilla-services] || Mozilla Services || [https://github.com/orgs/mozilla-services/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-services owners]|| [https://github.com/mozilla-services/github-management/issues Open Issue]<br />
|-<br />
| [https://github.com/mozilla-mobile/ mozilla-mobile] || Mobile: Android Product Team & Firefox iOS teams || [https://github.com/orgs/mozilla-mobile/people?utf8=%E2%9C%93&query=role%3Aowner mozilla-mobile owners]||<br />
|-<br />
| [https://github.com/mozilla-spidermonkey mozilla-spidermonkey] || Mozilla SpiderMonkey Team tools and embedding info || #jsapi||<br />
|-<br />
| [https://github.com/mozilla-standards mozilla-standards] || Mozilla Standards (for IPR Contributions) || [https://mozillians.org/u/dbaron/ dbaron], [https://mozillians.org/u/annevk/ annevk]||<br />
|-<br />
| [https://github.com/mozilla-svcops mozilla-svcops] || Mozilla Cloud Services Ops || {{Mozillian|relud|Daniel Thornton}}||<br />
|-<br />
| [https://github.com/Mozilla-TWQA Mozilla-TWQA] || Mozilla Taiwan QA || ?||<br />
|-<br />
| [https://github.com/mozillahispano mozillahispano] || Mozilla Hispano || ?||<br />
|-<br />
| [https://github.com/MozillaReality MozillaReality] || Mozilla Mixed Reality program || {{Mozillian|larsberg|Lars Bergstrom}}, {{Mozillian|plamb|Philip Lamb}}||<br />
|-<br />
| [https://github.com/MozillaResearch MozillaResearch ] || Mozilla Research space|| {{Mozillian|larsberg|Lars Bergstrom}}||<br />
|-<br />
| [https://github.com/MozillaScience MozillaScience] || Mozilla Science Lab || ?||<br />
|-<br />
| [https://github.com/MozillaSecurity MozillaSecurity] || Mozilla Platform Fuzzing Team master repo with many fuzzing tools under it. || ?||<br />
|-<br />
| [https://github.com/MozillaWiki MozillaWiki] || MozillaWiki (wiki.mozilla.org) || {{Mozillian|ckoehler|Christie Koehler}}, {{Mozillian|gphemsley|Gordon P. Hemsley}}||<br />
|-<br />
| [https://github.com/mozillayvr mozillayvr] || Mozilla Vancouver @MozillaYVR || {{Mozillian|bclark|Brian Clark}}, {{Mozillian|shobson|Stephanie Hobson}}||<br />
|-<br />
| [https://github.com/mozfr mozfr] || Mozilla Francophone ||||<br />
|-<br />
| [https://github.com/opennews opennews] || Knight-Mozilla OpenNews || ?||<br />
|-<br />
| [https://github.com/rust-lang rust-lang] || The Rust Programming Language || {{Mozillian|aturon|Aaron Turon}}||<br />
|-<br />
| [https://github.com/servo servo] || Servo (browser engine written in Rust) || {{Mozillian|larsberg|Lars Bergstrom}}, {{Mozillian|jdm|Josh Matthews}}||<br />
|-<br />
| [https://github.com/mozilla-l10n mozilla-l10n] || Mozilla l10n-drivers team || Francesco Lodolo https://mozillians.org/u/flod/||<br />
|-<br />
| [https://github.com/taskcluster taskcluster] || [[TaskCluster]] Team || [https://github.com/gregarndt Greg Arndt]||<br />
|-<br />
| [https://github.com/MozillaCH MozillaCH] || Mozilla [[Switzerland]] || {{Mozillian|mkohler|Michael Kohler}}, {{Mozillian|freaktechnik|freaktechnik}}||<br />
|-<br />
| [https://github.com/mozmeao MozMEAO] || Mozilla [[Marketing]] || {{Mozillian|bensternthal|Benjamin Sternthal}}, {{Mozillian|pmac|Paul McLanahan}}||<br />
|-<br />
| [https://github.com/mozilla-payments mozilla-payments] || Implementation of Web Payment APIs || {{Mozillian|Marcos Caceres}}||<br />
|-<br />
| [https://github.com/mozilla-jetpack mozilla-jetpack] || Resources for Mozilla's Add-on SDK || ?||<br />
|-<br />
| [https://github.com/web-ext-experiments web-ext-experiments] || WebExtension API Experiments || {{Mozillian|andym|Andy McKay}}||<br />
|-<br />
| [https://github.com/mozilla-conduit mozilla-conduit] || Mozilla Conduit work || {{Mozillian|glob|glob}}||<br />
|-<br />
| [https://github.com/mozsearch mozsearch] || The code that runs Searchfox.org || {{Mozillian|kats|Kartikaya Gupta}}||<br />
|-<br />
| [https://github.com/MozillaCZ/ MozillaCZ] || [https://www.mozilla.cz/ Mozilla.cz] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|MekliCZ|Michal Vašíček}}, {{Mozillian|zelitomas|Tomáš Zelina}}||<br />
|-<br />
| [https://github.com/MozillaSK/ MozillaSK] || [https://www.mozilla.sk/ Mozilla.sk] || {{Mozillian|mstanke|Michal Stanke}}, {{Mozillian|kusavica|Juraj Cigáň}}||<br />
|-<br />
| [https://github.com/MozillaDataScience MozillaDataScience] || Ad-hoc analyses by data scientists. || Matrix: #data-science:mozilla.org ||<br />
|-<br />
| [https://github.com/mozilla-extensions mozilla-extensions] || CI- and release-enabled privileged webextensions and system addons. || Slack: #addon-pipeline ||<br />
|}<br />
<br />
=== Are there other unofficial or Mozilla-related repositories hosted on Github? ===<br />
Why, yes! In no particular order:<br />
<br />
* [https://github.com/kinetiknz/cubeb/ https://github.com/kinetiknz/cubeb/] : Cubeb cross platform audio library.<br />
* [https://github.com/djg/cubeb-rs/ https://github.com/djg/cubeb-rs/] : Rust bindings for cubeb.<br />
* [https://github.com/kinetiknz/nestegg/ https://github.com/kinetiknz/nestegg/] : WebM demuxer.<br />
* [https://github.com/xiph/opus/ https://github.com/xiph/opus/] : Modern audio compression for the internet.<br />
* [https://github.com/webmproject/libvpx https://github.com/webmproject/libvpx] : Mirror only. Please do not send pull requests.<br />
* [https://github.com/campd/fxdt-adapters https://github.com/campd/fxdt-adapters] : Firefox Developer Tools protocol adapters<br />
* [https://github.com/kripken/emscripten https://github.com/kripken/emscripten] : Emscripten: An LLVM-to-JavaScript Compiler<br />
* [https://github.com/bbondy/codefirefox https://github.com/bbondy/codefirefox] : Video and exercise based tutorial site for coding Firefox and other Mozilla related technology<br />
* [https://github.com/nickdesaulniers/where-is-firefox-os https://github.com/nickdesaulniers/where-is-firefox-os] : A map showing where in the world Firefox OS phones are being sold.<br />
* [https://github.com/jdm/bugsahoy https://github.com/jdm/bugsahoy] : A landing page to make finding relevant bugs easier for new Mozilla contributors.<br />
* [https://github.com/w3c/web-platform-tests https://github.com/w3c/web-platform-tests] : Test Suites for Web Platform specifications<br />
* [https://github.com/w3c/wptserve https://github.com/w3c/wptserve] : Web server designed for use with web-platform-tests<br />
* [https://github.com/w3c/wptrunner https://github.com/w3c/wptrunner] : Cross-browser and multi-platform test runner for web-platform-tests. Used in mozilla-central and servo.<br />
* [https://github.com/w3c/testharness.js https://github.com/w3c/testharness.js] : (no description)<br />
* [https://github.com/jdm/asknot https://github.com/jdm/asknot] : Ask not what Mozilla can do for you but what you can do for Mozilla.<br />
* [https://github.com/jeffbryner/MozDef https://github.com/jeffbryner/MozDef]: Mozilla Defense Platform.<br />
* [https://github.com/jgraham/webdriver-rust https://github.com/jgraham/webdriver-rust]: WebDriver library for Rust.<br />
* [https://github.com/ehsan/mozilla-cvs-history https://github.com/ehsan/mozilla-cvs-history]: A git conversion of the full Mozilla CVS history, useful for code archaeology.<br />
* [https://github.com/djg/audioipc-2 https://github.com/djg/audioipc-2]: Audio IPC for Gecko.<br />
* [https://github.com/hsivonen/encoding_rs https://github.com/hsivonen/encoding_rs]: encoding_rs (character encoding converters for Gecko)<br />
* [https://github.com/choller/firefox-asan-reporter https://github.com/choller/firefox-asan-reporter] : Internal addon used in conjunction with special ASan builds of Firefox.<br />
* [https://github.com/jrmuizel/qcms https://github.com/jrmuizel/qcms] : Fork of 'quick color management' for Firefox<br />
* https://github.com/webcompat : Web Compatibility Team (Industry wide) -- {{Mozillian|miketaylr|Mike Taylor}}</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Process_release_email&diff=1227843ReleaseEngineering/How To/Process release email2020-06-02T17:27:47Z<p>Asasaki: adhoc, no more cot gpg</p>
<hr />
<div>{{Release Engineering How To|Process email to release@}}<br />
This is a list of automatically generated emails you should expect to receive as a release engineer at mozilla. It is not complete.<br />
<br />
Note that email is not a good notification methodology, and better systems should always be preferred. However, it often is all that is available for audience which needs the notification. To minimize the pain of email notifications, follow these guidelines:<br />
* email should go to a unique address for the service. This can be achieved by using "plus addresses" (preferred due to positive filtering criterea). (Note: AWS SES refers to these as "labels".)<br />
** if not possible, the message MUST have a unique start to the subject field (brittle).<br />
* email should be documented on this page.<br />
<br />
Some email is also routed to archives, which you may prefer to search instead of joining a list to receive emails:<br />
* [https://groups.google.com/a/mozilla.com/forum/#!forum/releng-puppet-mail releng puppet email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/release-automation-notifications release automation email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/releng-ops-trial vcs-sync operations email]<br />
<br />
= Index =<br />
''Note:'' The "Wildcard" column gives a suggestion on how to filter for that email.<br />
<br />
{| cellpadding="10" cellspacing="0" border="1" class="fullwidth-table sortable"<br />
!Field !! Wildcard !! Further Notes<br />
|-<br />
|Subject || collapse report || [[#Performance Metrics]]<br />
|-<br />
|Subject || Suspected machine issue (* || Not an actionable email at this point. (from: nobody@cruncher - s/a {{bug|825625}}<br />
|-<br />
|Subject ||Talos Suspected machine issue *|| ''if you don't know, you don't care''<br />
|-<br />
|Subject ||Try submission *||to: autolanduser@mozilla.com<br />
|-<br />
|Subject ||[vcs2vcs] alert_major_errors* || '''major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs]: git.m.o push N failed: * || single occurrence related to git.m.o/releases/gecko.git '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs] process delays* || '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject || [release-runner] failed || [[#What_to_do_when_one_is_received_6| How to investigate release runner failures]]. ''(ignore if a release isn't actively being started)''<br />
|-<br />
|To || release+amp@mozilla.com || Test Google Play store account. Blassey and Snorp have access. RelEng does not have access at this time.<br />
|-<br />
|To || release+aws@mozilla.com || AWS admin email, service notifications & marketing. See [[#Amazon_EC2_Instance_scheduled_for_retirement|list of AWS emails]], contact catlee if unsure how to handle.<br />
|-<br />
|To || release+bitbucket@mozilla.com || Mozilla Bitbucket Admin email (contact hwine for now)<br />
|-<br />
|To || release+aws-sanity-check@mozilla.com || Output from cruncher [http://hg.mozilla.org/build/cloud-tools/file/default/aws/aws_sanity_checker.py aws_sanity_checker.py] (contact rail)<br />
|-<br />
|To || release+ec2.*@mozilla.com || error output from crontab on the indicated machine. FIX ISSUE!<br />
|-<br />
|To || release+sns@mozilla.com || SNS issue notifications from various services. FIX ISSUE!<br />
|-<br />
|To || release+chromecast@mozilla.com || Developer account for Chromecast app support {{bug|1037018}} ([[#chromecast|details]])<br />
|-<br />
|To || release+v2v-gh@mozilla.com || Primary email for github account moz-v2v-gh. Contact vcs-sync folk<br />
|-<br />
|To || release+roku@mozilla.com || Primary email for Roku account, mfinkle is dev contact<br />
|-<br />
|To || release+signaddons@mozilla.com || Primary email for signing addons in automation via API<br />
|-<br />
|To || release+ubuntu-store@mozilla.com || Primary email for Ubuntu Store<br />
|-<br />
|To || release+mozdef@mozilla.com || Security alerts from infosec's Mozdef server. Alert team&infosec if you find suspicious activity.<br />
|-<br />
|To || release+moc_notifications@mozilla.com || Something from the MOC. Action depends on content. (Cited in [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana].)<br />
|-<br />
|To || release+appleagent@mozilla.com || Related to Apple ID account -- bring to manager's attention if lots of activity.<br />
|-<br />
|To || release+wcw@mozilla.com & release+wmw@mozilla.com || Requests for Wednesday Change Window (mana link to come). CiDuty or manager should respond.<br />
|-<br />
|To || release+github@mozilla.com || GitHub private repo access, esp partners + xpi.<br />
|}<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
=Performance Metrics=<br />
== Why we get them ==<br />
We get various emails containing raw data that relates to a performance bottle neck at some point in time. Typically these are produced by cron jobs, and so received regularly regardless of metric status. (I.e. they may not require any action.)<br />
<br />
== What is sending them ==<br />
Since this is a "catch all" category, various tools send them. Check the full headers for information on sender and source machine as needed.<br />
<br />
== What to do when one is received ==<br />
If you don't know what it's about, you don't need to deal with it beyond setting up a filter to ignore it.<br />
<br />
== How to silence or acknowledge this alert ==<br />
It's not an alert, so they'll keep coming until the end of time. Filter them if you're not involved with them.<br />
<br />
== Future plans ==<br />
Adhoc, so varies by email. Theoretically, these ''should'' be transitional, and moved into automation and alerting as soon as the metric is understood.<br />
<br />
== How to best filter these emails ==<br />
Since these are adhoc, you'll need adhoc filters. It would be nice if folks used a common prefix on subjects, such as "<tt><nowiki>[releng metrics]</nowiki></tt>".<br />
<br />
<div id="vcs2vcs"> </div><br />
= vcs2vcs System=<br />
== Why we get them ==<br />
These emails are the interim notification for vcs2vcs system, and indicate an error that must be addressed. The b2g project is dependent upon parts of the vcs2vcs system, as are other developers and partners.<br />
<br />
== What is sending them ==<br />
All emails are sent (perhaps indirectly) by a script from [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/ vcs2vcs tools]. The hosts sending the email will be one of the ones listed in [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-configs/file/default/status the configs]. Full details of how each script is run, including trouble shooting tips, are in the [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/file/default/docs docs] (a formatted copy ''may'' be online [http://people.mozilla.com/~hwine/tmp/vcs2vcs/ here]).<br />
<br />
== What to do when one is received ==<br />
* if the subject contains "[vcs2vcs] AUTOFIX process delays", then look for another email within a few minutes and proceed as follows:<br />
** if a second email from the same host follows almost immediately with a subject of "[vcs2vcs] process delays", then the AUTOFIX failed, which is an unexpected condition. Page hwine.<br />
** if no followup email is received, the AUTOFIX worked. Log in {{bug|829025}} & delete (or just delete and leave for hwine to log).<br />
* if the subject contains "[vcs2vcs] process delays" '''''and''''' is repeated every 20 minutes, this is a service outage - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or PAGE hwine. <br />
** Unfortunately, there appear to be a few race conditions between scripts, so a single occurrence of the email may be a false positive. ({{bug|839595}} filed to track this.)<br />
<br />
* if the subject contains "[vcs2vcs] alert_major_errors alert", this is a major problem - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or contact hwine. <br />
** The most common cause of this is hg repo corruption, the recovery is scripted, but can take some time. Please add to {{bug|808129}} if you fix, or block that bug with a new bug.<br />
** NOTE: you may receive an additional email after the root cause is resolved. (The alert checks on the hour for problems in the prior hour.)<br />
<br />
* if the subject containes "[vcs2vcs]: git.m.o push N failed for gecko.git:", this is a (usually) transient problem with pushing gecko.git (the partner facing gecko repository) to either git.m.o or git staging. Two pushes are tried each iteration - both should succeed. Each push is numbered '1' or '2', if you see only one email report, the other already succeeded, and is ignorable. One or two sets of emails is ignorable, any more needs investigation, starting with the health of git.mozilla.org. (Note that the message is short, as this also pages hwine via sms, where brevity is nice.)<br />
<br />
* if the subject is something else, this is likely unexpected output from a cron job. Judge the severity and escalate to hwine appropriately. File a bug to get better diagnosis of this error condition in the future.<br />
<br />
== How to silence or acknowledge this alert ==<br />
Resolving the root cause will stop the emails.<br />
<br />
== Future plans ==<br />
The system will eventually be transitioned to Developer Productivity (nee Developer Services (nee IT)) for operations. Specific email will be converted to nagios alerts before then.<br />
<br />
== How to best filter these emails ==<br />
All of these emails are sent to the addresses of the form: <tt>release+vcs2vcs*@mozilla.com</tt>. Common sub addresses are:<br />
; release+vcs2vcs : mail that will have specifics in the Subject line.<br />
; release+vcs2vcs+forward : mail to vcs2vcs user, forwarded via <tt>~/.forward</tt> file.<br />
<br />
= Release runner =<br />
== Why we get them ==<br />
Release runner sends e-mail when it fails in any way. Eg, failing to poll ship it after a long period of time or failing to start a submitted release.<br />
<br />
== What is sending them ==<br />
* Source: https://hg.mozilla.org/build/tools/file/default/buildfarm/release<br />
* Sent by: buildbot<br />
* Runs on: buildbot-master36 through supervisord<br />
<br />
== What to do when one is received ==<br />
[[Release:Release_Automation_on_Mercurial:Troubleshooting#How_to_investigate_release_runner_failures | How to invesigate release runner failures]]<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix whatever problem release runner has hit. (Sometimes this means waiting out network issues.) There's no way to ack (in the nagios sense) release runner e-mails.<br />
<br />
== Future plans ==<br />
They're here to stay.<br />
<br />
== How to best filter these emails ==<br />
[release-runner] in the subject.<br />
<br />
=Amazon EC2 Instance scheduled for retirement=<br />
==Example==<br />
One or more of your Amazon EC2 instances in the us-east-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2013-10-22.<br />
<br />
i-02cc2669<br />
<br />
== Why we get them ==<br />
Amazon needs us to move our virtual instance(s) off of certain physical hardware so they can perform maintenance on it.<br />
<br />
== What is sending them ==<br />
Automated notification sent by no-reply-aws@amazon.com<br />
<br />
== What to do when one is received ==<br />
* determine what host is running on the specified EC2 instance.<br />
* power the instance down in an orderly manner<br />
* start it back up<br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
Filter on the sender and subject line.<br />
<br />
=SNS Notifications from AWS=<br />
==Example==<br />
Anything with the Subject "AWS Notification Message"<br />
<br />
== Why we get them ==<br />
We use SNS to deliver notifications about various Amazon services as well as services like Papertrail. These are generally critical alerts that we've set up and should be dealt with/investigated in a timely fashion. At the moment, only AWS Cloudwatch and Papertrail use this service, but we will likely add more in the future after we get an SNS->irc bot set up because it allows for an easy HTTP/HTTPS endpoint push that other services already integrate with.<br />
<br />
== What is sending them ==<br />
The Amazon SNS service notification topic "buildduty"<br />
* arn:aws:sns:us-west-2:314336048151:buildduty<br />
* arn:aws:sns:us-east-1:314336048151:buildduty<br />
<br />
== What to do when one is received ==<br />
Determine what the issue is by parsing the output. Make sure someone is working on fixing the issue (if you're not sure how, at least contact ciduty for their input/advice).<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix the underlying issue to stop the alert.<br />
<br />
== Future plans ==<br />
In the near future we intend to send SNS notifications to an irc bot instead of via email.<br />
<br />
== How to best filter these emails ==<br />
Ideally you should not filter them except into a high priority folder. You can filter on the Subject or the To address.<br />
<br />
<div id="chromecast"></div><br />
<br />
= Mail to release+chromecast@mozilla.com =<br />
== Why we get them ==<br />
The mobile team is adding Chromecast support (ability to fling videos/tabs from a device to a TV). They need a persistent account not linked to a single developer who might leave the company at some point.<br />
<br />
== What is sending them ==<br />
These emails come from the <br />
<br />
== What to do when one is received ==<br />
Traffic should be light. If the email is not simply Google self-promotion, please forward it to lead mobile devs, namely :blassey and :mfinkle. <br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
You can either filter on the "To:" field for "release+chromecast@mozilla.com" to catch just these emails, or filter on "From:" for "noreply@google.com" and move all mail from Google (we have multiple accounts mailing us intermittently) to a separate Google subfolder (coop).<br />
<br />
<hr /><br />
<small><br />
<br />
<br />
=Security Alerts from Mozdef=<br />
== Why we get them ==<br />
Mozdef is an ELK stack (logging aggregator + parser) run by the infosec team. They're consuming our Papertrail logs, at our request.<br />
<br />
2016.09.13: We have asked them to create some preliminary alerts on ssh access to our signing infrastructure. See https://bugzilla.mozilla.org/show_bug.cgi?id=1290261<br />
<br />
== What is sending them ==<br />
2016.09.13: the infosec team has a cron job finding ssh activity on the signing infrastructure, and that emails us.<br />
<br />
== What to do when one is received ==<br />
2016.09.13: The emails are very new. For now, we most likely want to take a look and see what the 'normal' looks like, so we know when something out of the ordinary happens.<br />
<br />
On suspicious email, notify the team and infosec.<br />
<br />
== How to silence or acknowledge this alert ==<br />
2016.10.08: These will send once an hour if there is ssh access.<br />
<br />
== Future plans ==<br />
2016.09.13: We may change the frequency of the emails to be more immediate, once we know the noise level.<br />
<br />
== How to best filter these emails ==<br />
As noted in the table above, these are sent to release+mozdef@mozilla.com<br />
<br />
<br />
=Mail to release+moc_notifications@mozilla.com=<br />
== Why we get them ==<br />
Unsure when MOC will use this address.<br />
<br />
== What is sending them ==<br />
Humans from MOC will use this address.<br />
<br />
== What to do when one is received ==<br />
* Read and handle<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
Unknown - check [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana] to see if anything has changed.<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
<br />
=Mail to release+appleagent@mozilla.com=<br />
== Why we get them ==<br />
* 2 step verification<br />
* fall back account<br />
<br />
== What is sending them ==<br />
Apple when folks interact with the release Apple ID agent account.<br />
<br />
== What to do when one is received ==<br />
* If you generated it, claim it by reply.<br />
* Unclaimed emails should be escalated to folks with access to release Apple ID accounts<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
=Sample=<br />
== Why we get them ==<br />
Give a brief explanation of why this email is for, what it helps us do and why it should be watched<br />
<br />
== What is sending them ==<br />
Include a link to the source of the program sending the email. Include information on which hosts are sending the email, and give information on how program runs. Is it a daemon? Does it have an init script? Do you run it under screen? <br />
<br />
== What to do when one is received ==<br />
* if the title contains "[scl-production-puppet-new] <slavename> is waiting to be signed", this is for information and requires no immediate action<br />
* if the title contains "[scl-production-puppet-new] <slavename> has invalid cert", the script will try once to clean the cert before sending the email. If this is successful, you'll see a matching "<slavename> is waiting to be signed" email. The key will be automatically signed<br />
<br />
== How to silence or acknowledge this alert ==<br />
Include information on how to make the emails stop<br />
<br />
== Future plans ==<br />
provide any future plans for this email. Is it temporary? Is it going to be replaced by a real dashboard? Are you going to add/change things people filter on?<br />
<br />
== How to best filter these emails ==<br />
provide insight on how to filter these emails. Is there a distinguishing header? Is it always from a specifc host, or family of hosts? Is there a distinctive subject?<br />
<br />
=Mail to release+adhoc-signing@mozilla.com=<br />
== Why we get them ==<br />
* adhoc repo release promotion<br />
<br />
== What is sending them ==<br />
https://github.com/mozilla-releng/adhoc-signing relpro<br />
<br />
== What to do when one is received ==<br />
* Make sure we're expecting an adhoc signing operation<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
</small></div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Process_release_email&diff=1226985ReleaseEngineering/How To/Process release email2020-05-08T21:42:56Z<p>Asasaki: add release+github, remove some older release aliases</p>
<hr />
<div>{{Release Engineering How To|Process email to release@}}<br />
This is a list of automatically generated emails you should expect to receive as a release engineer at mozilla. It is not complete.<br />
<br />
Note that email is not a good notification methodology, and better systems should always be preferred. However, it often is all that is available for audience which needs the notification. To minimize the pain of email notifications, follow these guidelines:<br />
* email should go to a unique address for the service. This can be achieved by using "plus addresses" (preferred due to positive filtering criterea). (Note: AWS SES refers to these as "labels".)<br />
** if not possible, the message MUST have a unique start to the subject field (brittle).<br />
* email should be documented on this page.<br />
<br />
Some email is also routed to archives, which you may prefer to search instead of joining a list to receive emails:<br />
* [https://groups.google.com/a/mozilla.com/forum/#!forum/releng-puppet-mail releng puppet email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/release-automation-notifications release automation email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/releng-ops-trial vcs-sync operations email]<br />
<br />
= Index =<br />
''Note:'' The "Wildcard" column gives a suggestion on how to filter for that email.<br />
<br />
{| cellpadding="10" cellspacing="0" border="1" class="fullwidth-table sortable"<br />
!Field !! Wildcard !! Further Notes<br />
|-<br />
|Subject || collapse report || [[#Performance Metrics]]<br />
|-<br />
|Subject || Suspected machine issue (* || Not an actionable email at this point. (from: nobody@cruncher - s/a {{bug|825625}}<br />
|-<br />
|Subject ||Talos Suspected machine issue *|| ''if you don't know, you don't care''<br />
|-<br />
|Subject ||Try submission *||to: autolanduser@mozilla.com<br />
|-<br />
|Subject ||[vcs2vcs] alert_major_errors* || '''major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs]: git.m.o push N failed: * || single occurrence related to git.m.o/releases/gecko.git '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs] process delays* || '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject || [release-runner] failed || [[#What_to_do_when_one_is_received_6| How to investigate release runner failures]]. ''(ignore if a release isn't actively being started)''<br />
|-<br />
|To || release+amp@mozilla.com || Test Google Play store account. Blassey and Snorp have access. RelEng does not have access at this time.<br />
|-<br />
|To || release+aws@mozilla.com || AWS admin email, service notifications & marketing. See [[#Amazon_EC2_Instance_scheduled_for_retirement|list of AWS emails]], contact catlee if unsure how to handle.<br />
|-<br />
|To || release+bitbucket@mozilla.com || Mozilla Bitbucket Admin email (contact hwine for now)<br />
|-<br />
|To || release+aws-sanity-check@mozilla.com || Output from cruncher [http://hg.mozilla.org/build/cloud-tools/file/default/aws/aws_sanity_checker.py aws_sanity_checker.py] (contact rail)<br />
|-<br />
|To || release+ec2.*@mozilla.com || error output from crontab on the indicated machine. FIX ISSUE!<br />
|-<br />
|To || release+sns@mozilla.com || SNS issue notifications from various services. FIX ISSUE!<br />
|-<br />
|To || release+chromecast@mozilla.com || Developer account for Chromecast app support {{bug|1037018}} ([[#chromecast|details]])<br />
|-<br />
|To || release+v2v-gh@mozilla.com || Primary email for github account moz-v2v-gh. Contact vcs-sync folk<br />
|-<br />
|To || release+roku@mozilla.com || Primary email for Roku account, mfinkle is dev contact<br />
|-<br />
|To || release+signaddons@mozilla.com || Primary email for signing addons in automation via API<br />
|-<br />
|To || release+ubuntu-store@mozilla.com || Primary email for Ubuntu Store<br />
|-<br />
|To || release+mozdef@mozilla.com || Security alerts from infosec's Mozdef server. Alert team&infosec if you find suspicious activity.<br />
|-<br />
|To || release+moc_notifications@mozilla.com || Something from the MOC. Action depends on content. (Cited in [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana].)<br />
|-<br />
|To || release+appleagent@mozilla.com || Related to Apple ID account -- bring to manager's attention if lots of activity.<br />
|-<br />
|To || release+wcw@mozilla.com & release+wmw@mozilla.com || Requests for Wednesday Change Window (mana link to come). CiDuty or manager should respond.<br />
|-<br />
|To || release+github@mozilla.com || GitHub private repo access, esp partners + xpi.<br />
|}<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
=Performance Metrics=<br />
== Why we get them ==<br />
We get various emails containing raw data that relates to a performance bottle neck at some point in time. Typically these are produced by cron jobs, and so received regularly regardless of metric status. (I.e. they may not require any action.)<br />
<br />
== What is sending them ==<br />
Since this is a "catch all" category, various tools send them. Check the full headers for information on sender and source machine as needed.<br />
<br />
== What to do when one is received ==<br />
If you don't know what it's about, you don't need to deal with it beyond setting up a filter to ignore it.<br />
<br />
== How to silence or acknowledge this alert ==<br />
It's not an alert, so they'll keep coming until the end of time. Filter them if you're not involved with them.<br />
<br />
== Future plans ==<br />
Adhoc, so varies by email. Theoretically, these ''should'' be transitional, and moved into automation and alerting as soon as the metric is understood.<br />
<br />
== How to best filter these emails ==<br />
Since these are adhoc, you'll need adhoc filters. It would be nice if folks used a common prefix on subjects, such as "<tt><nowiki>[releng metrics]</nowiki></tt>".<br />
<br />
<div id="vcs2vcs"> </div><br />
= vcs2vcs System=<br />
== Why we get them ==<br />
These emails are the interim notification for vcs2vcs system, and indicate an error that must be addressed. The b2g project is dependent upon parts of the vcs2vcs system, as are other developers and partners.<br />
<br />
== What is sending them ==<br />
All emails are sent (perhaps indirectly) by a script from [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/ vcs2vcs tools]. The hosts sending the email will be one of the ones listed in [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-configs/file/default/status the configs]. Full details of how each script is run, including trouble shooting tips, are in the [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/file/default/docs docs] (a formatted copy ''may'' be online [http://people.mozilla.com/~hwine/tmp/vcs2vcs/ here]).<br />
<br />
== What to do when one is received ==<br />
* if the subject contains "[vcs2vcs] AUTOFIX process delays", then look for another email within a few minutes and proceed as follows:<br />
** if a second email from the same host follows almost immediately with a subject of "[vcs2vcs] process delays", then the AUTOFIX failed, which is an unexpected condition. Page hwine.<br />
** if no followup email is received, the AUTOFIX worked. Log in {{bug|829025}} & delete (or just delete and leave for hwine to log).<br />
* if the subject contains "[vcs2vcs] process delays" '''''and''''' is repeated every 20 minutes, this is a service outage - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or PAGE hwine. <br />
** Unfortunately, there appear to be a few race conditions between scripts, so a single occurrence of the email may be a false positive. ({{bug|839595}} filed to track this.)<br />
<br />
* if the subject contains "[vcs2vcs] alert_major_errors alert", this is a major problem - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or contact hwine. <br />
** The most common cause of this is hg repo corruption, the recovery is scripted, but can take some time. Please add to {{bug|808129}} if you fix, or block that bug with a new bug.<br />
** NOTE: you may receive an additional email after the root cause is resolved. (The alert checks on the hour for problems in the prior hour.)<br />
<br />
* if the subject containes "[vcs2vcs]: git.m.o push N failed for gecko.git:", this is a (usually) transient problem with pushing gecko.git (the partner facing gecko repository) to either git.m.o or git staging. Two pushes are tried each iteration - both should succeed. Each push is numbered '1' or '2', if you see only one email report, the other already succeeded, and is ignorable. One or two sets of emails is ignorable, any more needs investigation, starting with the health of git.mozilla.org. (Note that the message is short, as this also pages hwine via sms, where brevity is nice.)<br />
<br />
* if the subject is something else, this is likely unexpected output from a cron job. Judge the severity and escalate to hwine appropriately. File a bug to get better diagnosis of this error condition in the future.<br />
<br />
== How to silence or acknowledge this alert ==<br />
Resolving the root cause will stop the emails.<br />
<br />
== Future plans ==<br />
The system will eventually be transitioned to Developer Productivity (nee Developer Services (nee IT)) for operations. Specific email will be converted to nagios alerts before then.<br />
<br />
== How to best filter these emails ==<br />
All of these emails are sent to the addresses of the form: <tt>release+vcs2vcs*@mozilla.com</tt>. Common sub addresses are:<br />
; release+vcs2vcs : mail that will have specifics in the Subject line.<br />
; release+vcs2vcs+forward : mail to vcs2vcs user, forwarded via <tt>~/.forward</tt> file.<br />
<br />
= Release runner =<br />
== Why we get them ==<br />
Release runner sends e-mail when it fails in any way. Eg, failing to poll ship it after a long period of time or failing to start a submitted release.<br />
<br />
== What is sending them ==<br />
* Source: https://hg.mozilla.org/build/tools/file/default/buildfarm/release<br />
* Sent by: buildbot<br />
* Runs on: buildbot-master36 through supervisord<br />
<br />
== What to do when one is received ==<br />
[[Release:Release_Automation_on_Mercurial:Troubleshooting#How_to_investigate_release_runner_failures | How to invesigate release runner failures]]<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix whatever problem release runner has hit. (Sometimes this means waiting out network issues.) There's no way to ack (in the nagios sense) release runner e-mails.<br />
<br />
== Future plans ==<br />
They're here to stay.<br />
<br />
== How to best filter these emails ==<br />
[release-runner] in the subject.<br />
<br />
=Amazon EC2 Instance scheduled for retirement=<br />
==Example==<br />
One or more of your Amazon EC2 instances in the us-east-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2013-10-22.<br />
<br />
i-02cc2669<br />
<br />
== Why we get them ==<br />
Amazon needs us to move our virtual instance(s) off of certain physical hardware so they can perform maintenance on it.<br />
<br />
== What is sending them ==<br />
Automated notification sent by no-reply-aws@amazon.com<br />
<br />
== What to do when one is received ==<br />
* determine what host is running on the specified EC2 instance.<br />
* power the instance down in an orderly manner<br />
* start it back up<br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
Filter on the sender and subject line.<br />
<br />
=SNS Notifications from AWS=<br />
==Example==<br />
Anything with the Subject "AWS Notification Message"<br />
<br />
== Why we get them ==<br />
We use SNS to deliver notifications about various Amazon services as well as services like Papertrail. These are generally critical alerts that we've set up and should be dealt with/investigated in a timely fashion. At the moment, only AWS Cloudwatch and Papertrail use this service, but we will likely add more in the future after we get an SNS->irc bot set up because it allows for an easy HTTP/HTTPS endpoint push that other services already integrate with.<br />
<br />
== What is sending them ==<br />
The Amazon SNS service notification topic "buildduty"<br />
* arn:aws:sns:us-west-2:314336048151:buildduty<br />
* arn:aws:sns:us-east-1:314336048151:buildduty<br />
<br />
== What to do when one is received ==<br />
Determine what the issue is by parsing the output. Make sure someone is working on fixing the issue (if you're not sure how, at least contact ciduty for their input/advice).<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix the underlying issue to stop the alert.<br />
<br />
== Future plans ==<br />
In the near future we intend to send SNS notifications to an irc bot instead of via email.<br />
<br />
== How to best filter these emails ==<br />
Ideally you should not filter them except into a high priority folder. You can filter on the Subject or the To address.<br />
<br />
<div id="chromecast"></div><br />
<br />
= Mail to release+chromecast@mozilla.com =<br />
== Why we get them ==<br />
The mobile team is adding Chromecast support (ability to fling videos/tabs from a device to a TV). They need a persistent account not linked to a single developer who might leave the company at some point.<br />
<br />
== What is sending them ==<br />
These emails come from the <br />
<br />
== What to do when one is received ==<br />
Traffic should be light. If the email is not simply Google self-promotion, please forward it to lead mobile devs, namely :blassey and :mfinkle. <br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
You can either filter on the "To:" field for "release+chromecast@mozilla.com" to catch just these emails, or filter on "From:" for "noreply@google.com" and move all mail from Google (we have multiple accounts mailing us intermittently) to a separate Google subfolder (coop).<br />
<br />
<hr /><br />
<small><br />
<br />
<br />
=Security Alerts from Mozdef=<br />
== Why we get them ==<br />
Mozdef is an ELK stack (logging aggregator + parser) run by the infosec team. They're consuming our Papertrail logs, at our request.<br />
<br />
2016.09.13: We have asked them to create some preliminary alerts on ssh access to our signing infrastructure. See https://bugzilla.mozilla.org/show_bug.cgi?id=1290261<br />
<br />
== What is sending them ==<br />
2016.09.13: the infosec team has a cron job finding ssh activity on the signing infrastructure, and that emails us.<br />
<br />
== What to do when one is received ==<br />
2016.09.13: The emails are very new. For now, we most likely want to take a look and see what the 'normal' looks like, so we know when something out of the ordinary happens.<br />
<br />
On suspicious email, notify the team and infosec.<br />
<br />
== How to silence or acknowledge this alert ==<br />
2016.10.08: These will send once an hour if there is ssh access.<br />
<br />
== Future plans ==<br />
2016.09.13: We may change the frequency of the emails to be more immediate, once we know the noise level.<br />
<br />
== How to best filter these emails ==<br />
As noted in the table above, these are sent to release+mozdef@mozilla.com<br />
<br />
<br />
=Mail to release+moc_notifications@mozilla.com=<br />
== Why we get them ==<br />
Unsure when MOC will use this address.<br />
<br />
== What is sending them ==<br />
Humans from MOC will use this address.<br />
<br />
== What to do when one is received ==<br />
* Read and handle<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
Unknown - check [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana] to see if anything has changed.<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
<br />
=Mail to release+appleagent@mozilla.com=<br />
== Why we get them ==<br />
* 2 step verification<br />
* fall back account<br />
<br />
== What is sending them ==<br />
Apple when folks interact with the release Apple ID agent account.<br />
<br />
== What to do when one is received ==<br />
* If you generated it, claim it by reply.<br />
* Unclaimed emails should be escalated to folks with access to release Apple ID accounts<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
=Sample=<br />
== Why we get them ==<br />
Give a brief explanation of why this email is for, what it helps us do and why it should be watched<br />
<br />
== What is sending them ==<br />
Include a link to the source of the program sending the email. Include information on which hosts are sending the email, and give information on how program runs. Is it a daemon? Does it have an init script? Do you run it under screen? <br />
<br />
== What to do when one is received ==<br />
* if the title contains "[scl-production-puppet-new] <slavename> is waiting to be signed", this is for information and requires no immediate action<br />
* if the title contains "[scl-production-puppet-new] <slavename> has invalid cert", the script will try once to clean the cert before sending the email. If this is successful, you'll see a matching "<slavename> is waiting to be signed" email. The key will be automatically signed<br />
<br />
== How to silence or acknowledge this alert ==<br />
Include information on how to make the emails stop<br />
<br />
== Future plans ==<br />
provide any future plans for this email. Is it temporary? Is it going to be replaced by a real dashboard? Are you going to add/change things people filter on?<br />
<br />
== How to best filter these emails ==<br />
provide insight on how to filter these emails. Is there a distinguishing header? Is it always from a specifc host, or family of hosts? Is there a distinctive subject?<br />
<br />
=Mail to release+cot@mozilla.com=<br />
== Why we get them ==<br />
* gpg pubkey expiration monitoring ([https://bugzilla.mozilla.org/show_bug.cgi?id=1373986]) <br />
<br />
== What is sending them ==<br />
https://tools.taskcluster.net/hooks/project-releng/cot-gpg-keys%2Fexpiration<br />
<br />
== What to do when one is received ==<br />
* Alert the cot-gpg-keys contributors [https://github.com/mozilla-releng/cot-gpg-keys/graphs/contributors]<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
</small></div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Tips_And_Tricks&diff=1204804ReleaseEngineering/Tips And Tricks2018-12-05T16:53:24Z<p>Asasaki: /* Firefox Addons */changed my addons</p>
<hr />
<div>__TOC__<br />
= Bugzilla =<br />
* mtabara Bugzilla filtering in GMail<br />
** toggle the include-X-headers in the body from https://bugzilla.mozilla.org/userprefs.cgi<br />
** https://github.com/rail/dotfiles/blob/master/imapfilter.config.lua<br />
<br />
= Firefox Addons =<br />
* aki: tree style tab<br />
* aki: forest<br />
* aki: multi-container and temporary containers<br />
* jlorenzo: AutoHiDPI for 4K screen alongside a regular 1080p<br />
* jlorenzo: U2F addon for 2FA on Github<br />
* jlund: vimfx (minimal addon that provides nice vim functionality without the bloat and bustage of pentadactyl and the like<br />
* jlund: open multiple urls: https://addons.mozilla.org/en-US/firefox/addon/open-multiple-urls/?src=api<br />
** this one is handy since buildapi/running is borked as it lets you open all the buildmasters really fast at a certain builder (I have the builders saved in a file and just change the buildername)<br />
http://buildbot-master70.bb.releng.use1.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master71.bb.releng.use1.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master72.bb.releng.usw2.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master73.bb.releng.usw2.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master74.bb.releng.usw2.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master77.bb.releng.use1.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master82.bb.releng.scl3.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master84.bb.releng.scl3.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master85.bb.releng.scl3.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master86.bb.releng.scl3.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master91.bb.releng.usw2.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
http://buildbot-master94.bb.releng.use1.mozilla.com:8001/builders/release-mozilla-beta-firefox-win64_partner_repacks<br />
* coop: jsonovich - json formatting (not needed on aurora)<br />
* coop: whimsy pro<br />
* coop: stylish, because playing with CSS is fun<br />
* coop: wikiwand<br />
* Callek: tab stats<br />
* hal: uBlock Origin, lastpass, <br />
* catlee: User Agent Switcher<br />
* catlee; U2F addon<br />
* catlee: no more 404s<br />
<br />
= Misc =<br />
* Travel guide: https://wiki.mozilla.org/Travel_Guide<br />
<br />
= Python =<br />
* mtabara: pdb and tasks<br />
* rail: using ipydb<br />
<br />
= Shell =<br />
* TaskWarrior: https://vreplay.mozilla.com/replay/showRecordingExternal.html?key=mWl5zc3txxqP4TQ<br />
* https://mana.mozilla.org/wiki/display/RelEng/URL+hacking+for+releng+systems<br />
* jlund taking back control of your ssh agent<br />
<br />
# set an ssh key expiry within your agent<br />
renew_ssh_agent ()<br />
{<br />
(umask 066; ssh-agent > ~/.ssh/ssh-agent)<br />
eval "$(<~/.ssh/ssh-agent)" >/dev/null<br />
}<br />
<br />
start_ssh_agent ()<br />
{<br />
if [ ! -f ~/.ssh/ssh-agent ]; then<br />
renew_ssh_agent<br />
else<br />
eval "$(<~/.ssh/ssh-agent)" >/dev/null<br />
fi<br />
<br />
ssh-add -l &>/dev/null<br />
ssh_add_rc="$?"<br />
if [ $ssh_add_rc = 1 ] || [ $ssh_add_rc = 2 ]; then<br />
if [ $ssh_add_rc = 2 ]; then<br />
# ssh-agent defined in ~/.ssh/ssh-agent doesn't exist, recreate<br />
renew_ssh_agent<br />
fi<br />
# set timelimit to 4 hours<br />
ssh-add -t 14400<br />
fi<br />
}<br />
start_ssh_agent<br />
<br />
= Vidyo =<br />
* !mtabara: you can join a vidyo room muted<br />
<br />
= Vim =<br />
* vim tricks: https://vreplay.mozilla.com/replay/showRecordingExternal.html?key=il1OYf2kd5qS2we<br />
* mtabara: vim vs IDE for python?<br />
** whatever makes you happy<br />
** catlee: watchdog has a tool called watchmedo for automatic testing, <br />
** catlee: while (inotifywait -q -q -e close_write -r *; true); do tox; done<br />
* vim extensions<br />
** aki likes foldmethod markers: {{{1<br />
** aki likes regexes across lines: :76,92s,^, , # indent lines 76-92 4 spaces deeper<br />
** sfraser couldn't live without an autopep8 formatter</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:NextReleaseDate&diff=1202410Template:NextReleaseDate2018-10-15T22:46:34Z<p>Asasaki: </p>
<hr />
<div>2018-12-11</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:Version/Gecko/beta/current&diff=1202408Template:Version/Gecko/beta/current2018-10-15T22:44:53Z<p>Asasaki: 64</p>
<hr />
<div>64</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:Version/Gecko/release/next&diff=1202407Template:Version/Gecko/release/next2018-10-15T22:44:30Z<p>Asasaki: 64</p>
<hr />
<div>64</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:Version/Gecko/release/current&diff=1202406Template:Version/Gecko/release/current2018-10-15T22:44:07Z<p>Asasaki: 63.0.0</p>
<hr />
<div>63.0.0</div>Asasakihttps://wiki.mozilla.org/index.php?title=Release_Management/Release_owners&diff=1201646Release Management/Release owners2018-09-27T17:13:37Z<p>Asasaki: aki is also on releaseduty this cycle</p>
<hr />
<div>{{DISPLAYTITLE:Firefox Release Owners}}<br />
==Release Owners==<br />
<br />
* For any questions related to landing of particular features, Beta scheduling, preffing on/off a feature, release notes etc for a particular Firefox version on any channel, below would be the best contacts in addition to emailing release-mgmt@mozilla.com<br />
<br />
Currently, each release manager each takes a version of Firefox and follow it from nightly through beta, and release. Whoever has just done a release will then "own" the next ESR and work on the new nightly.<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
!Firefox Version<br />
!Owner<br />
!Secondary<br />
!Eng support<br />
!Releng¹ <br />
!Corresponding ESR<br />
!Release date<br />
|-<br />
|Firefox 64<br />
|Julien<br />
|RyanVM<br />
|<br />
|<br />
|Liz<br />
|2018-12-11<br />
|-<br />
|Firefox 63<br />
|Pascal<br />
|Ritu<br />
|ddurst<br />
|rail, aki, garbas<br />
|Julien<br />
|2018-10-23<br />
|-<br />
|Firefox 62<br />
|Lizzard<br />
|Pascal<br />
|Mike T <br />
|jlorenzo, tomprince <br />
|RyanVM<br />
|2018-09-05<br />
|-<br />
|Firefox 61<br />
|RyanVM<br />
|Ritu<br />
|Marion <br />
|mtabara, jlund<br />
|Julien<br />
|2018-06-26<br />
|-<br />
|Firefox 60 (an ESR)<br />
|Julien<br />
|Ritu<br />
|Milan <br />
|aki, sfraser<br />
|Liz (52.8)<br />
|2018-05-09<br />
|-<br />
|Firefox 59<br />
|Liz<br />
|RyanVM<br />
|Andrew Overholt<br />
|mtabara, bhearsum<br />
|RyanVM<br />
|2018-03-13<br />
|-<br />
|Firefox 58<br />
|Gerry<br />
|Julien<br />
|Mike Taylor <br />
|callek, sfraser, nthomas, rok, jlund<br />
|Ritu<br />
|2018-01-23<br />
|-<br />
|Firefox 57<br />
|Ritu Kothari<br />
|Julien Cristau & Sylvestre<br />
|Jim Mathies<br />
|callek, jlorenzo, nthomas, sfraser, jlund<br />
|Liz<br />
|2017-11-14<br />
|-<br />
|Firefox 56<br />
|Liz Henry<br />
|Gerry Chang<br />
|Panos Astithas<br />
|kmoir, sfraser<br />
|Julien Cristau<br />
|2017-09-26<br />
|-<br />
|Firefox 55<br />
|Julien Cristau<br />
|Liz Henry<br />
|Mike Taylor<br />
|garbas, mtabara<br />
|Gerry Chang<br />
|2017-08-08<br />
|-<br />
|Firefox 54<br />
|Gerry Chang<br />
|Julien Cristau<br />
|Nathan Froyd<br />
|mtabara, aki<br />
|Ritu<br />
|2017-06-13<br />
|-<br />
|Firefox 53<br />
|Liz Henry<br />
|Gerry Chang<br />
|Randell Jesup<br />
|aki, jlorenzo<br />
|Julien Cristau<br />
|2017-04-18<br />
|-<br />
|Firefox 52<br />
|Julien Cristau<br />
|Sylvestre<br />
|RyanVM<br />
|jlorenzo, jlund<br />
|Gerry<br />
|2017-03-07<br />
|-<br />
|Firefox 51<br />
|Gerry Chang<br />
|Liz Henry<br />
|Milan<br />
|jlund, mtabara<br />
|Ritu<br />
|2017-01-24 <br />
|}<br />
<br />
=== Eng support ===<br />
This lists the Regression Engineering Owner for the release. Details at https://wiki.mozilla.org/Platform#Regression_Engineering_Owner_.28REO.29 <br />
<br />
=== ¹ - Releng Coverage Notes ===<br />
Release Engineering will provide 24/5 coverage (PT Sun-Fri) with varying levels of support for 57.0 and the 58.0 cycle. See [https://calendar.google.com/calendar/embed?src=mozilla.com_v37shpb9uef44a7dbmjngdai1c%40group.calendar.google.com Releng Releaseduty Coverage] calendar for specific availability and local timezone.<br />
<br />
Releng covers a given release beginning at the second beta for the cycle listed and ending on the first beta shipment of the follow-up cycle.<br />
<br />
[[Category:Release_Management]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/PuppetAgain/HowTo/Set_up_a_user_environment&diff=1196411ReleaseEngineering/PuppetAgain/HowTo/Set up a user environment2018-06-28T16:40:42Z<p>Asasaki: scl3 -> mdc1. also move the --environment arg for easier copy/paste with env edit</p>
<hr />
<div>Approved people have SSH logins on all puppet masters and a puppet environment at /etc/puppet/environments/$username.<br />
<br />
You can use this environment to do your development.<br />
<br />
= Common =<br />
<br />
== On the master machine ==<br />
<br />
In general, you'll want to clone https://github.com/mozilla/build-puppet at /etc/puppet/environments/$USER. You can use git if you'd like, doesn't matter. Then link in the config and nodes for the org you're working with; for moco, that's:<br />
<br />
cd /etc/puppet/environments/$USER/manifests<br />
ln -s moco-config.pp config.pp<br />
ln -s moco-nodes.pp nodes.pp<br />
<br />
== On the worker node(s) ==<br />
<br />
Next, you can run puppet agent on a worker and tell it to use your environment on the server you've selected:<br />
<br />
$ su -<br />
# puppet agent --test --server=releng-puppet2.srv.releng.mdc1.mozilla.com --environment=dmitchell<br />
<br />
On a mac worker, on the first run you will have to specify the ssl dir. For example:<br />
<br />
$ su -<br />
# puppet agent --test --server=releng-puppet2.srv.releng.mdc1.mozilla.com --environment=kmoir --pluginsync --ssldir=/var/lib/puppet/ssl<br />
<br />
== Secrets (back on master node) ==<br />
<br />
Note that your secrets will come from the same Hiera datasource as everything else. You can override secrets for your env only in <tt>/etc/hiera/environments/<yourname>_secrets.eyaml</tt>.<br />
<br />
= Problems =<br />
<br />
The most common problem that you'll see is that your version control system will helpfully make the files in your repository not world-readable, and in particular preclude puppet from reading them.<br />
<br />
This will result in this error message when try to run puppet on your worker<br />
"Could not parse for environment $yourid: Permission denied"<br />
in /etc/puppet/environments/$yourid<br />
<br />
find . -type f | xargs chmod o+r<br />
find . -type d | xargs chmod o+rx<br />
<br />
This ''should'' not be a problem anymore - puppet is now a member of each user's group, so it should be able to read the repository with the 'g' permissions. Please file bugs or contact dustin for any permissions problems.<br />
<br />
= Pinning =<br />
<br />
If you want to make a node use your environment on every run (e.g., for workers that run puppet at boot), you can "pin" the host to your environment. Edit the node definition like this:<br />
node "hostname" {<br />
# the pins must come *before* the toplevel include<br />
$pin_puppet_server = "releng-puppet2.srv.releng.mdc1.mozilla.com"<br />
$pin_puppet_env = "dmitchell"<br />
include toplevel::slave::releng::build<br />
}<br />
<br />
This will result in a puppet.conf on the client that specifies the server and environment.<br />
<br />
= Git =<br />
<br />
If you're using git, set things up as follows:<br />
<br />
cd /etc/puppet/environments/$USER<br />
git init<br />
<br />
edit .git/config, and add<br />
<br />
sharedRepository = 0644<br />
<br />
to the [core] section. Then clone a copy of the git repository (e.g., from http://github.com/mozilla/build-puppet), and start hacking.<br />
<br />
git remote add mozilla git@github.com:mozilla/build-puppet.git<br />
git fetch mozilla<br />
git reset --hard mozilla/master</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:NextReleaseDate&diff=1193419Template:NextReleaseDate2018-05-07T21:17:25Z<p>Asasaki: 05/09</p>
<hr />
<div>2018-05-09</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:Version/Gecko/beta/current&diff=1193418Template:Version/Gecko/beta/current2018-05-07T21:16:44Z<p>Asasaki: 61</p>
<hr />
<div>61</div>Asasakihttps://wiki.mozilla.org/index.php?title=Template:Version/Gecko/central/current&diff=1193417Template:Version/Gecko/central/current2018-05-07T21:15:15Z<p>Asasaki: 62</p>
<hr />
<div>62</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1181867ReleaseEngineering/DisposableProjectRepositories2017-10-05T17:32:44Z<p>Asasaki: clear out ash</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to repo to clone from] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* After Developer Services runs the reset, they will also notify the teams who operate the automation, so they can adjust their schedulers to recognize the reset. (This needs to happen on both legacy buildbot & taskcluster schedulers.) If you don't see the expected builds, check with the automation teams to ensure their reset occurred.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| <br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|1364561}}<br />
| jgraham@mozilla.com<br />
| wpt-sync<br />
| 2017-09-06 - 2017-12-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| {{bug|1358168}}<br />
| dolske@mozilla.com<br />
| :dolske, Photon project usage<br />
| 2016-04-20 - 2017-08-15<br />
|<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1288182}}<br />
| l10n@mozilla.com<br />
| :Pike, for l20n work<br />
| 2016-07-20 - 2016-11-15<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| mhowell@mozilla.com, rstrong@mozilla.com<br />
| mhowell, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|137122}}<br />
| dmose@mozilla.org<br />
| :dmose,:k88hudson,:Mardak,:ursula green up activity-stream in prep for landing<br />
| 2017-02-05 - 2017-06-10<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| disabled<br />
| disabled<br />
| disabled<br />
| disabled<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1259143}}<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| Release promotion<br />
| 2016-03-23 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| disabled<br />
| disabled<br />
| disabled<br />
| disabled<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| {{bug|1397773}}<br />
| aki@mozilla.com<br />
| tc release promotion<br />
| 2017-10-02 - indefinite<br />
| -<br />
|}</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/DisposableProjectRepositories&diff=1181866ReleaseEngineering/DisposableProjectRepositories2017-10-05T17:29:53Z<p>Asasaki: update date / birch / maple</p>
<hr />
<div>== What is a disposable project branch? ==<br />
These are project branches that can be cloned fresh from any mozilla-central based repo with the full gamut of tests enabled. No l10n or<br />
nightlies for now. Similar to [[ReleaseEngineering/TryServer|TryServer]] but for longer, and just for '''you'''. Unlike Try, the commit level on these branches is '''level_2 (and above) contributors only''' so please bear that in mind.<br />
<br />
===Do you need a disposable branch?===<br />
Ask yourself the following:<br />
<br />
'''Does your project have an end date?'''<br />
<br />
If your answer is '''No''' then you should follow the process at [https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning Project Branch Planning]<br />
<br />
<br />
If your project is a temporary feature sprint that needs its own rapid test coverage but will eventually be merged into mozilla-central and no longer be on its own by all means, please go ahead and <br />
<br />
===Book one of our fabulous "disposable" project branches===<br />
'''''NOTE:''''' The number of disposable branches is limited by CI capacity. If there are no available branches, contact the owners of existing branches to see if you can "sub let".<br />
<br />
* Sign up below in the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]]<br />
* Make a [https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer%20Services&component=Mercurial:%20hg.mozilla.org&short_desc=Requesting%20twig%20repo%20{booked_repo}%20be%20reset&comment=Please%20run%20the%20{script_name}%20and%20reset%20{booked_repo}%20to%20{url}&cc=buildduty@releng.bugs request] (example: {{bug|951811}}) to IT to reset the repo for you as a clone from your own project repo (or default mozilla-central:tip). '''Copy the script below into bug request, replacing the REPO_PATH and TWIG with your repo and booked branch'''.<br />
<pre><br />
export REPO_PATH=[path to repo to clone from] # eg: users/lsblakk_mozilla.com/staging or comm-central<br />
export TWIG=[alder|birch|cedar|holly|larch|maple] # whichever twig you booked<br />
<br />
cd /repo/hg/scripts/<br />
./reset_pp_repo.sh -s /repo/hg/mozilla/$REPO_PATH -r tip -d $TWIG<br />
</pre><br />
* '''NOTE''': Your repository will have no hooks enabled after a reset. You'll need to specify in the request if you need any configured.<br />
* After Developer Services runs the reset, they will also notify the teams who operate the automation, so they can adjust their schedulers to recognize the reset. (This needs to happen on both legacy buildbot & taskcluster schedulers.) If you don't see the expected builds, check with the automation teams to ensure their reset occurred.<br />
* Sit back and watch your builds and test results roll in (eg [http://tbpl.mozilla.org/?tree=Alder Alder], [http://tbpl.mozilla.org/?tree=Birch Birch], [http://tbpl.mozilla.org/?tree=Cedar Cedar],[http://tbpl.mozilla.org/?tree=Holly Holly], [http://tbpl.mozilla.org/?tree=Larch Larch], [http://tbpl.mozilla.org/?tree=Maple Maple]). <br />
<br />
<div id="unbook"></div><br />
<br />
===When you're done with one of our fabulous "disposable" project branches===<br />
<br />
Simply clear your data (bug, contact, dates) from the [[#BOOKING_SCHEDULE|BOOKING SCHEDULE]] below. If someone is listed in the "Next in Line" column, please let them know you are done.<br />
<br />
That's all there is to it!<br />
<br />
== Using a custom mozconfig ==<br />
<br />
The mozconfigs used for builds live in the same source tree as the main code, eg<br />
* Firefox: <tt>browser/config/mozconfigs/<platform></tt><br />
* Mobile Native: <tt>mobile/android/config/mozconfigs/android</tt><br />
* Mobile XUL: <tt>mobile/xul/config/mozconfigs/android-xul</tt><br />
<br />
The 'nightly' file is used for optimised builds, 'debug' for debug. If you are unsure which file you need consult a build log to see which is used. You can adjust these as needed on your branch, and they will be carried over to mozilla-central when you merge back. Please take care with any mozconfig changes you merge back (eg exclude local conveniences).<br />
<br />
==Enabling/Disabling of platforms, tests, nightly updates ==<br />
If the specific builds/tests you want are not enabled, or if there are builds/tests which you do not need on your branch, ask RelEng to enable/disable them by filing a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=Release%20Engineering here].<br />
<br />
Nightly builds and updates are disabled by default but can be enabled on request.<br />
<br />
== BOOKING SCHEDULE ==<br />
<br />
{| class="data wikitable"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates <br />
! Next in Line<br />
|-<br />
|<br />
|<br />
|<br />
|<br />
|<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=ash Ash]<br />
| {{bug|1252292}}<br />
| jgriffin@mozilla.com<br />
| e10s tests<br />
| 2016-03-01 - TBD<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cypress Cypress]<br />
| {{bug|1222301}}<br />
| Pidgeot18@gmail.com<br />
| <br />
| <br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=elm Elm]<br />
| {{bug|1364561}}<br />
| jgraham@mozilla.com<br />
| wpt-sync<br />
| 2017-09-06 - 2017-12-31<br />
|<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=cedar Cedar]<br />
| {{bug|1358168}}<br />
| dolske@mozilla.com<br />
| :dolske, Photon project usage<br />
| 2016-04-20 - 2017-08-15<br />
|<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=fig Fig]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=gum Gum]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| <strike>[https://treeherder.mozilla.org/#/jobs?repo=holly Holly]</strike><br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
| retired<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=larch Larch]<br />
| {{bug|1288182}}<br />
| l10n@mozilla.com<br />
| :Pike, for l20n work<br />
| 2016-07-20 - 2016-11-15<br />
| <br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=oak Oak]<br />
| {{bug|790467}} and other risky updater work<br />
| mhowell@mozilla.com, rstrong@mozilla.com<br />
| mhowell, rstrong<br />
| 2012-09-11 - 2015-12-31 '''''<span color="yellow">PENDING</span>'''''<br />
| -<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=pine Pine]<br />
| {{bug|137122}}<br />
| dmose@mozilla.org<br />
| :dmose,:k88hudson,:Mardak,:ursula green up activity-stream in prep for landing<br />
| 2017-02-05 - 2017-06-10<br />
| -<br />
|}<br />
<br />
Be sure to keep a copy of anything you need from the repo prior to [[#unbook|unbooking]] it.<br />
<br />
== Indefinite booking ==<br />
See also [[ReleaseEngineering/SpecialBranches]] for more info on these branches.<br />
{| class="data"<br />
|-<br />
! Project Branch<br />
! Regist. bug<br />
! email address of borrower<br />
! User/Dev Team contact <br />
! Booking Dates<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=date Date]<br />
| -<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| disabled<br />
| disabled<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=jamun Jamun]<br />
| {{bug|1259143}}<br />
| rail@mozilla.com, jlund@mozilla.com<br />
| Release promotion<br />
| 2016-03-23 - indefinite<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=birch Birch]<br />
| <br />
| catlee@mozilla.com<br />
| disabled<br />
| disabled<br />
|-<br />
| [https://treeherder.mozilla.org/#/jobs?repo=maple Maple]<br />
| {{bug|1397773}}<br />
| aki@mozilla.com<br />
| tc release promotion<br />
| 2017-10-02 - indefinite<br />
| -<br />
|}</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Process_release_email&diff=1181413ReleaseEngineering/How To/Process release email2017-09-28T20:43:25Z<p>Asasaki: release+cot</p>
<hr />
<div>{{Release Engineering How To|Process email to release@}}<br />
This is a list of automatically generated emails you should expect to receive as a release engineer at mozilla. It is not complete.<br />
<br />
Note that email is not a good notification methodology, and better systems should always be preferred. However, it often is all that is available for audience which needs the notification. To minimize the pain of email notifications, follow these guidelines:<br />
* email should go to a unique address for the service. This can be achieved by using "plus addresses" (preferred due to positive filtering criterea). (Note: AWS SES refers to these as "labels".)<br />
** if not possible, the message MUST have a unique start to the subject field (brittle).<br />
* email should be documented on this page.<br />
<br />
Some email is also routed to archives, which you may prefer to search instead of joining a list to receive emails:<br />
* [https://groups.google.com/a/mozilla.com/forum/#!forum/releng-puppet-mail releng puppet email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/release-automation-notifications release automation email]<br />
* [https://groups.google.com/a/mozilla.com/forum/?hl=en#!forum/releng-ops-trial vcs-sync operations email]<br />
<br />
= Index =<br />
''Note:'' The "Wildcard" column gives a suggestion on how to filter for that email.<br />
<br />
{| cellpadding="10" cellspacing="0" border="1" class="fullwidth-table sortable"<br />
!Field !! Wildcard !! Further Notes<br />
|-<br />
|Subject || collapse report || [[#Performance Metrics]]<br />
|-<br />
|Subject || Suspected machine issue (* || Not an actionable email at this point. (from: nobody@cruncher - s/a {{bug|825625}}<br />
|-<br />
|Subject ||Talos Suspected machine issue *|| ''if you don't know, you don't care''<br />
|-<br />
|Subject ||Try submission *||to: autolanduser@mozilla.com<br />
|-<br />
|Subject ||[vcs2vcs] alert_major_errors* || '''major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs]: git.m.o push N failed: * || single occurrence related to git.m.o/releases/gecko.git '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject ||[vcs2vcs] process delays* || '''if repeated, this is a major processing error''' make sure build duty and/or hwine know [[#vcs2vcs|details]]<br />
|-<br />
|Subject || [release-runner] failed || [[#What_to_do_when_one_is_received_6| How to investigate release runner failures]]. ''(ignore if a release isn't actively being started)''<br />
|-<br />
|To || release+amp@mozilla.com || Test Google Play store account. Blassey and Snorp have access. RelEng does not have access at this time.<br />
|-<br />
|To || release+aws@mozilla.com || AWS admin email, service notifications & marketing. See [[#Amazon_EC2_Instance_scheduled_for_retirement|list of AWS emails]], contact catlee if unsure how to handle.<br />
|-<br />
|To || release+bitbucket@mozilla.com || Mozilla Bitbucket Admin email (contact hwine for now)<br />
|-<br />
|To || release+vcs2vcs@mozilla.com || Output from vcs2vcs hg<->git conversion ([[#vcs2vcs|details]])<br />
|-<br />
|To || release+aws-sanity-check@mozilla.com || Output from cruncher [http://hg.mozilla.org/build/cloud-tools/file/default/aws/aws_sanity_checker.py aws_sanity_checker.py] (contact rail)<br />
|-<br />
|To || release+ec2.*@mozilla.com || error output from crontab on the indicated machine. FIX ISSUE!<br />
|-<br />
|To || release+sns@mozilla.com || SNS issue notifications from various services. FIX ISSUE!<br />
|-<br />
|To || release+update.b2g.o@mozilla.com || low disk space on dogfood update server, see {{bug|877224}}<br />
|-<br />
|To || release+chromecast@mozilla.com || Developer account for Chromecast app support {{bug|1037018}} ([[#chromecast|details]])<br />
|-<br />
|To || release+v2v-gh@mozilla.com || Primary email for github account moz-v2v-gh. Contact vcs-sync folk<br />
|-<br />
|To || release+roku@mozilla.com || Primary email for Roku account, mfinkle is dev contact<br />
|-<br />
|To || release+signaddons@mozilla.com || Primary email for signing addons in automation via API<br />
|-<br />
|To || release+ubuntu-store@mozilla.com || Primary email for Ubuntu Store<br />
|-<br />
|To || release+mozdef@mozilla.com || Security alerts from infosec's Mozdef server. Alert team&infosec if you find suspicious activity.<br />
|-<br />
|To || release+moc_notifications@mozilla.com || Something from the MOC. Action depends on content. (Cited in [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana].)<br />
|-<br />
|To || release+appleagent@mozilla.com || Related to Apple ID account -- bring to manager's attention if lots of activity.<br />
|-<br />
|To || release+wcw@mozilla.com & release+wmw@mozilla.com || Requests for Wednesday Change Window (mana link to come). Buildduty or manager should respond.<br />
|-<br />
|To || release+cot@mozilla.com || GPG expiration monitoring. Alert aki, catlee, garndt.<br />
|}<br />
<br />
<br /><br />
<br />
__TOC__<br />
<br />
=Performance Metrics=<br />
== Why we get them ==<br />
We get various emails containing raw data that relates to a performance bottle neck at some point in time. Typically these are produced by cron jobs, and so received regularly regardless of metric status. (I.e. they may not require any action.)<br />
<br />
== What is sending them ==<br />
Since this is a "catch all" category, various tools send them. Check the full headers for information on sender and source machine as needed.<br />
<br />
== What to do when one is received ==<br />
If you don't know what it's about, you don't need to deal with it beyond setting up a filter to ignore it.<br />
<br />
== How to silence or acknowledge this alert ==<br />
It's not an alert, so they'll keep coming until the end of time. Filter them if you're not involved with them.<br />
<br />
== Future plans ==<br />
Adhoc, so varies by email. Theoretically, these ''should'' be transitional, and moved into automation and alerting as soon as the metric is understood.<br />
<br />
== How to best filter these emails ==<br />
Since these are adhoc, you'll need adhoc filters. It would be nice if folks used a common prefix on subjects, such as "<tt><nowiki>[releng metrics]</nowiki></tt>".<br />
<br />
<div id="vcs2vcs"> </div><br />
= vcs2vcs System=<br />
== Why we get them ==<br />
These emails are the interim notification for vcs2vcs system, and indicate an error that must be addressed. The b2g project is dependent upon parts of the vcs2vcs system, as are other developers and partners.<br />
<br />
== What is sending them ==<br />
All emails are sent (perhaps indirectly) by a script from [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/ vcs2vcs tools]. The hosts sending the email will be one of the ones listed in [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-configs/file/default/status the configs]. Full details of how each script is run, including trouble shooting tips, are in the [http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/file/default/docs docs] (a formatted copy ''may'' be online [http://people.mozilla.com/~hwine/tmp/vcs2vcs/ here]).<br />
<br />
== What to do when one is received ==<br />
* if the subject contains "[vcs2vcs] AUTOFIX process delays", then look for another email within a few minutes and proceed as follows:<br />
** if a second email from the same host follows almost immediately with a subject of "[vcs2vcs] process delays", then the AUTOFIX failed, which is an unexpected condition. Page hwine.<br />
** if no followup email is received, the AUTOFIX worked. Log in {{bug|829025}} & delete (or just delete and leave for hwine to log).<br />
* if the subject contains "[vcs2vcs] process delays" '''''and''''' is repeated every 20 minutes, this is a service outage - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or PAGE hwine. <br />
** Unfortunately, there appear to be a few race conditions between scripts, so a single occurrence of the email may be a false positive. ({{bug|839595}} filed to track this.)<br />
<br />
* if the subject contains "[vcs2vcs] alert_major_errors alert", this is a major problem - one or more repositories are no longer being updated. The email contents will give specific errors. Consult the trouble shooting section of the docs (above) for guidance and/or contact hwine. <br />
** The most common cause of this is hg repo corruption, the recovery is scripted, but can take some time. Please add to {{bug|808129}} if you fix, or block that bug with a new bug.<br />
** NOTE: you may receive an additional email after the root cause is resolved. (The alert checks on the hour for problems in the prior hour.)<br />
<br />
* if the subject containes "[vcs2vcs]: git.m.o push N failed for gecko.git:", this is a (usually) transient problem with pushing gecko.git (the partner facing gecko repository) to either git.m.o or git staging. Two pushes are tried each iteration - both should succeed. Each push is numbered '1' or '2', if you see only one email report, the other already succeeded, and is ignorable. One or two sets of emails is ignorable, any more needs investigation, starting with the health of git.mozilla.org. (Note that the message is short, as this also pages hwine via sms, where brevity is nice.)<br />
<br />
* if the subject is something else, this is likely unexpected output from a cron job. Judge the severity and escalate to hwine appropriately. File a bug to get better diagnosis of this error condition in the future.<br />
<br />
== How to silence or acknowledge this alert ==<br />
Resolving the root cause will stop the emails.<br />
<br />
== Future plans ==<br />
The system will eventually be transitioned to Developer Productivity (nee Developer Services (nee IT)) for operations. Specific email will be converted to nagios alerts before then.<br />
<br />
== How to best filter these emails ==<br />
All of these emails are sent to the addresses of the form: <tt>release+vcs2vcs*@mozilla.com</tt>. Common sub addresses are:<br />
; release+vcs2vcs : mail that will have specifics in the Subject line.<br />
; release+vcs2vcs+forward : mail to vcs2vcs user, forwarded via <tt>~/.forward</tt> file.<br />
<br />
= Release runner =<br />
== Why we get them ==<br />
Release runner sends e-mail when it fails in any way. Eg, failing to poll ship it after a long period of time or failing to start a submitted release.<br />
<br />
== What is sending them ==<br />
* Source: https://hg.mozilla.org/build/tools/file/default/buildfarm/release<br />
* Sent by: buildbot<br />
* Runs on: buildbot-master36 through supervisord<br />
<br />
== What to do when one is received ==<br />
[[Release:Release_Automation_on_Mercurial:Troubleshooting#How_to_investigate_release_runner_failures | How to invesigate release runner failures]]<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix whatever problem release runner has hit. (Sometimes this means waiting out network issues.) There's no way to ack (in the nagios sense) release runner e-mails.<br />
<br />
== Future plans ==<br />
They're here to stay.<br />
<br />
== How to best filter these emails ==<br />
[release-runner] in the subject.<br />
<br />
=Amazon EC2 Instance scheduled for retirement=<br />
==Example==<br />
One or more of your Amazon EC2 instances in the us-east-1 region is scheduled for retirement. The following instance(s) will be shut down after 12:00 AM UTC on 2013-10-22.<br />
<br />
i-02cc2669<br />
<br />
== Why we get them ==<br />
Amazon needs us to move our virtual instance(s) off of certain physical hardware so they can perform maintenance on it.<br />
<br />
== What is sending them ==<br />
Automated notification sent by no-reply-aws@amazon.com<br />
<br />
== What to do when one is received ==<br />
* determine what host is running on the specified EC2 instance.<br />
* power the instance down in an orderly manner<br />
* start it back up<br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
Filter on the sender and subject line.<br />
<br />
=SNS Notifications from AWS=<br />
==Example==<br />
Anything with the Subject "AWS Notification Message"<br />
<br />
== Why we get them ==<br />
We use SNS to deliver notifications about various Amazon services as well as services like Papertrail. These are generally critical alerts that we've set up and should be dealt with/investigated in a timely fashion. At the moment, only AWS Cloudwatch and Papertrail use this service, but we will likely add more in the future after we get an SNS->irc bot set up because it allows for an easy HTTP/HTTPS endpoint push that other services already integrate with.<br />
<br />
== What is sending them ==<br />
The Amazon SNS service notification topic "buildduty"<br />
* arn:aws:sns:us-west-2:314336048151:buildduty<br />
* arn:aws:sns:us-east-1:314336048151:buildduty<br />
<br />
== What to do when one is received ==<br />
Determine what the issue is by parsing the output. Make sure someone is working on fixing the issue (if you're not sure how, at least contact buildduty for their input/advice).<br />
<br />
== How to silence or acknowledge this alert ==<br />
Fix the underlying issue to stop the alert.<br />
<br />
== Future plans ==<br />
In the near future we intend to send SNS notifications to an irc bot instead of via email.<br />
<br />
== How to best filter these emails ==<br />
Ideally you should not filter them except into a high priority folder. You can filter on the Subject or the To address.<br />
<br />
<div id="chromecast"></div><br />
<br />
= Mail to release+chromecast@mozilla.com =<br />
== Why we get them ==<br />
The mobile team is adding Chromecast support (ability to fling videos/tabs from a device to a TV). They need a persistent account not linked to a single developer who might leave the company at some point.<br />
<br />
== What is sending them ==<br />
These emails come from the <br />
<br />
== What to do when one is received ==<br />
Traffic should be light. If the email is not simply Google self-promotion, please forward it to lead mobile devs, namely :blassey and :mfinkle. <br />
<br />
== How to silence or acknowledge this alert ==<br />
<br />
== Future plans ==<br />
<br />
== How to best filter these emails ==<br />
You can either filter on the "To:" field for "release+chromecast@mozilla.com" to catch just these emails, or filter on "From:" for "noreply@google.com" and move all mail from Google (we have multiple accounts mailing us intermittently) to a separate Google subfolder (coop).<br />
<br />
<hr /><br />
<small><br />
<br />
<br />
=Security Alerts from Mozdef=<br />
== Why we get them ==<br />
Mozdef is an ELK stack (logging aggregator + parser) run by the infosec team. They're consuming our Papertrail logs, at our request.<br />
<br />
2016.09.13: We have asked them to create some preliminary alerts on ssh access to our signing infrastructure. See https://bugzilla.mozilla.org/show_bug.cgi?id=1290261<br />
<br />
== What is sending them ==<br />
2016.09.13: the infosec team has a cron job finding ssh activity on the signing infrastructure, and that emails us.<br />
<br />
== What to do when one is received ==<br />
2016.09.13: The emails are very new. For now, we most likely want to take a look and see what the 'normal' looks like, so we know when something out of the ordinary happens.<br />
<br />
On suspicious email, notify the team and infosec.<br />
<br />
== How to silence or acknowledge this alert ==<br />
2016.10.08: These will send once an hour if there is ssh access.<br />
<br />
== Future plans ==<br />
2016.09.13: We may change the frequency of the emails to be more immediate, once we know the noise level.<br />
<br />
== How to best filter these emails ==<br />
As noted in the table above, these are sent to release+mozdef@mozilla.com<br />
<br />
<br />
=Mail to release+moc_notifications@mozilla.com=<br />
== Why we get them ==<br />
Unsure when MOC will use this address.<br />
<br />
== What is sending them ==<br />
Humans from MOC will use this address.<br />
<br />
== What to do when one is received ==<br />
* Read and handle<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
Unknown - check [https://mana.mozilla.org/wiki/display/MOC/MOC+Contact+Groups#MOCContactGroups-Teams mana] to see if anything has changed.<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
<br />
=Mail to release+appleagent@mozilla.com=<br />
== Why we get them ==<br />
* 2 step verification<br />
* fall back account<br />
<br />
== What is sending them ==<br />
Apple when folks interact with the release Apple ID agent account.<br />
<br />
== What to do when one is received ==<br />
* If you generated it, claim it by reply.<br />
* Unclaimed emails should be escalated to folks with access to release Apple ID accounts<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
<br />
=Sample=<br />
== Why we get them ==<br />
Give a brief explanation of why this email is for, what it helps us do and why it should be watched<br />
<br />
== What is sending them ==<br />
Include a link to the source of the program sending the email. Include information on which hosts are sending the email, and give information on how program runs. Is it a daemon? Does it have an init script? Do you run it under screen? <br />
<br />
== What to do when one is received ==<br />
* if the title contains "[scl-production-puppet-new] <slavename> is waiting to be signed", this is for information and requires no immediate action<br />
* if the title contains "[scl-production-puppet-new] <slavename> has invalid cert", the script will try once to clean the cert before sending the email. If this is successful, you'll see a matching "<slavename> is waiting to be signed" email. The key will be automatically signed<br />
<br />
== How to silence or acknowledge this alert ==<br />
Include information on how to make the emails stop<br />
<br />
== Future plans ==<br />
provide any future plans for this email. Is it temporary? Is it going to be replaced by a real dashboard? Are you going to add/change things people filter on?<br />
<br />
== How to best filter these emails ==<br />
provide insight on how to filter these emails. Is there a distinguishing header? Is it always from a specifc host, or family of hosts? Is there a distinctive subject?<br />
<br />
=Mail to release+cot@mozilla.com=<br />
== Why we get them ==<br />
* gpg pubkey expiration monitoring ([https://bugzilla.mozilla.org/show_bug.cgi?id=1373986]) <br />
<br />
== What is sending them ==<br />
https://tools.taskcluster.net/hooks/project-releng/cot-gpg-keys%2Fexpiration<br />
<br />
== What to do when one is received ==<br />
* Alert the cot-gpg-keys contributors [https://github.com/mozilla-releng/cot-gpg-keys/graphs/contributors]<br />
<br />
== How to silence or acknowledge this alert ==<br />
* depends on context<br />
<br />
== Future plans ==<br />
''none''<br />
<br />
== How to best filter these emails ==<br />
Filter by "to" address.<br />
</small></div>Asasakihttps://wiki.mozilla.org/index.php?title=CIDuty/Other_Duties&diff=1176654CIDuty/Other Duties2017-07-28T02:28:49Z<p>Asasaki: setup.exe -> target.zip for win dep</p>
<hr />
<div>__TOC__<br />
<br />
= Tree Maintenance =<br />
== Repo Errors ==<br />
If a dev reports a problem pushing to hg (either m-c or try repo) then you need to do the following:<br />
* File a bug (or have dev file it) and then poke in #ops noahm<br />
** If he doesn't respond, then escalate the bug to page on-call<br />
* Follow the steps below for "How do I close the tree"<br />
<br />
== How do I see problems in Treeherder? ==<br />
All "infrastructure" (that's us!) problems should be purple at https://treeherder.mozilla.org. Some aren't, so keep your eyes open in IRC, but get on any purples quickly.<br />
<br />
== How do I close the tree? ==<br />
See [[ReleaseEngineering/How_To/Close_or_Open_the_Tree]]<br />
<br />
== How do I claim a rentable project branch? ==<br />
See [[ReleaseEngineering/DisposableProjectBranches#BOOKING_SCHEDULE]]<br />
<br />
== Clean up the scheduler DB ==<br />
Sometimes we get some jobs pending for days:<br />
https://secure.pub.build.mozilla.org/buildapi/pending<br />
<br />
These are supposed to be cleaned up automatically now. See {{bug|755012}} for details.<br />
<br />
== Marking jobs as complete in the buildbot database ==<br />
Sometimes we get a commit with a weird char or charset in the commit message. This can sometimes cause scheduling to get stuck when buildbot hits an exception.<br />
<br />
In general, you shouldn't need to remove the job or sourcestamp. It's much simpler to simply mark the request and buildset as complete. Here's an example:<br />
<br />
# Setting results == 4 allows us to search for records changed this way.<br />
use buildbot_schedulers<br />
set @REVISION='e87f642fa4a9'<br />
update buildrequests set complete_at=UNIX_TIMESTAMP(),complete=1,results=4 \<br />
where buildsetid in (select id from buildsets where sourcestampid in \<br />
(select id from sourcestamps where revision like CONCAT(@REVISION,'%'));<br />
update buildsets set complete_at=UNIX_TIMESTAMP(),complete=1,results=4 \<br />
where sourcestampid in \<br />
(select id from sourcestamps where revision like CONCAT(@REVISION,'%'));<br />
<br />
= Re-run jobs =<br />
== How to trigger Talos jobs ==<br />
see [[ReleaseEngineering/How_To/Trigger_Talos_Jobs]]<br />
<br />
== How to re-trigger all Talos runs for a build (by using sendchange) ==<br />
see [[ReleaseEngineering/How_To/Trigger_Talos_Jobs]]<br />
<br />
== How to re-run a build ==<br />
Do ''not'' go to the page of the build you'd like to re-run and cook up a sendchange to try to re-create the change that caused it. Changes without revlinks trigger releases, which is not what you want.<br />
<br />
Find the revision you want, find a builder page for the builder you want (preferably, but not necessarily, on the same master), and plug the revision, your name, and a comment into the "Force Build" form. <em>Note that the '''YOU MUST''' specify the branch, so there's no null keys in the builds-running.js.</em> Otherwise your build will not show up in self-serve or Treeherder.<br />
<br />
= Nightlies =<br />
<br />
== How do I re-spin mozilla-central nightlies? ==<br />
=== To build new nightlies ===<br />
<br />
==== To build nightlies on all the platforms ====<br />
Note: as of Jan 17, 2017 we build nightlies for Android and Linux platform builds on Taskcluster. As of June 21, 2017 we build nightlies for Macosx on Taskcluster. As of July 26, 2017, we build nightlies for Windows builds on Taskcluster. In order to retrigger these nightlies by hand, you need to use the taskcluster tools.<br />
<br />
Login to taskcluster tools<br />
https://tools.taskcluster.net and goto tools<br />
<br />
To retrigger nightlies for Linux<br />
https://tools.taskcluster.net/hooks/#project-releng/nightly-desktop%252fmozilla-central<br />
<br />
To retrigger nightlies for Android<br />
https://tools.taskcluster.net/hooks/#project-releng/nightly-fennec%252fmozilla-central<br />
<br />
To retrigger nightlies for Macosx<br />
https://tools.taskcluster.net/hooks/project-releng/nightly-desktop-osx%2Fmozilla-central<br />
<br />
To retrigger nightlies for Windows (both win32 and win64)<br />
https://tools.taskcluster.net/hooks/project-releng/nightly-desktop-win%2Fmozilla-central<br />
<br />
Select the green "trigger hook" button at the bottom of the page.<br />
<br />
If you get an error about scopes, you might have to create a client id for this hook<br />
See https://tools.taskcluster.net/auth/clients/ for an example and use "mozilla-ldap/kmoir@mozilla.com/" in the "Client ids beginning with page"<br />
<br />
==== Where are nightly and dependant artifacts stored? ====<br />
<br />
With the move to taskcluster, build artifacts are no longer stored on archive.mozilla.org. Instead, they can be downloaded in two ways:<br />
<br />
1. Treeherder. With buildbot, the build + signing + repackaging of Firefox into the correct format for that platform was a single job, the nightly build. With the move to taskcluster, the installable artifacts are created in different job names. <br />
For Android and Linux, they are in the Ns (nightly signing) job. For Mac and Windows, they are in the Nr (nightly repackage) job. Here is a [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-job_type_symbol=Ns&filter-job_type_symbol=Nr filter for mozilla-central] that will display the job names you need to download the artifacts.<br />
<br />
<pre><br />
Platform Nightly Job Artifact to download<br />
Android* Ns target.apk<br />
Linux* Ns target.tar.bz2<br />
Mac Nr target.dmg<br />
Win* Nr installer.exe<br />
</pre><br />
<br />
For non-nightly builds, a [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&filter-job_type_symbol=B&filter-job_type_symbol=Bs useful filter for treeherder is here] (mozilla inbound as an example, update as appropriate). In this case, the job symbols are B for Android, Linux and Mac, and Bs for Windows (signed on push build for Windows as required by some tests).<br />
<br />
<pre><br />
Platform Dep Job Symbol Artifact to download<br />
Android* B target.apk<br />
Linux* B target.tar.bz2<br />
Mac B target.dmg<br />
Win* Bs target.zip<br />
</pre><br />
<br />
2. Indexes. Taskcluster indexes identify artifacts associated with each job. Look here for [https://tools.taskcluster.net/index/gecko.v2.mozilla-central.nightly.latest.firefox taskcluster nightlies, the latest desktop] and [https://tools.taskcluster.net/index/gecko.v2.mozilla-central.nightly.latest.mobile here for mobile]. Again, the jobs and artifacts associated with each nightly correspond the the chart above. Click on the appropriate job, then "Taskid" on the right, then "Run artifacts" on the right. For dep builds, [https://tools.taskcluster.net/index/gecko.v2.mozilla-central.latest.firefox look under for desktop] or [https://tools.taskcluster.net/index/gecko.v2.mozilla-central.latest.mobile here for mobile].<br />
<br />
== Disable updates ==<br />
<br />
See [[ReleaseEngineering/How_To/Shut_off_all_updates]] for global shutoff. We use Balrog now for nightly & aurora updates.<br />
<br />
== Freeze Updates ==<br />
See [[ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Central]] if you simply need to freeze updates and not completely disable.<br />
<br />
= Talos =<br />
== How to update the talos zips ==<br />
We only need to do this for mobile requests.<br />
<br />
'''This deployment is super safe. NPOTB'''<br />
<br />
<pre><br />
# running this from cruncher is faster than downloading/uploading from your localhost<br />
ssh -A cruncher <br />
export URL=http://people.mozilla.org/~jmaher/taloszips/zips/talos.07322bbe0f7d.zip<br />
export TALOS_ZIP=`basename $URL`<br />
wget $URL<br />
#relengwebadmn has limited access to the internet - that is why we scp from another host<br />
scp ${TALOS_ZIP} relengwebadm.private.scl3.mozilla.com:/mnt/netapp/relengweb/talos-bundles/zips<br />
ssh relengwebadm.private.scl3.mozilla.com "chmod 644 /mnt/netapp/relengweb/talos-bundles/zips/${TALOS_ZIP}"<br />
ssh relengwebadm.private.scl3.mozilla.com "sha1sum /mnt/netapp/relengweb/talos-bundles/zips/${TALOS_ZIP}"<br />
curl -I http://talos-bundles.pvt.build.mozilla.org/zips/${TALOS_ZIP}<br />
</pre><br />
<br />
For talos.zip changes: Once deployed, notify the a-team and let them know that they can land at their own convenience.<br />
<br />
* Please verify the shasum matches what is in the [[https://bugzilla.mozilla.org/show_bug.cgi?id=1002780#c6 comment]], we have had a few instances where the talos.zip was incorrect.<br />
<br />
== Update mobile talos webhosts ==<br />
<br />
Keep track of what revisions is being run. <br />
Copy/paste the output into the bug.<br />
Please update our [[ReleaseEngineering/Maintenance#Mobile_talos_webhost|maintenance page]]<br />
<br />
'''This could affect mobile talos numbers or break the jobs altogether. Please coordinate with sheriffs'''<br />
<br />
'''NOTE: There's a great deal of data we can not check into revision control for legal reasons, so there's an extensive .hgignore file. If you're adding new data to the tree that can not be checked in, please ask a talos developer/reviewer or [[https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=Talos file a bug]] to request any [[http://hg.mozilla.org/build/talos/file/8d6fb3704417/.hgignore .hgignore]] changes'''<br />
<br />
=== webapp cluster ===<br />
<br />
ssh relengwebadm.private.scl3.mozilla.com<br />
sudo su -<br />
cd /data/releng/src/talos-remote/www/talos-repo<br />
# NOTICE that we have uncommitted files<br />
hg status<br />
# Take note of the current revision to revert to (just in case)<br />
hg id<br />
hg pull -u<br />
# 488bc187a3ef tip<br />
# ..capture the output here; the remainder will be long and not that useful..<br />
/data/releng/src/talos-remote/update<br />
<br />
=== Tp4 Zip ===<br />
<br />
###<br />
### NOTE UNTESTED AFTER BUG 1050769 -- Please remove this warning next use<br />
###<br />
ssh -A cruncher <br />
export URL=http://people.mozilla.org/~jmaher/taloszips/zips/mobile_tp4.zip<br />
export TALOS_ZIP=`basename $URL`<br />
wget $URL<br />
scp ${TALOS_ZIP} `whoami`@relengwebadm.private.scl3.mozilla.com:.<br />
<br />
# Connect to root @ relengwebadm<br />
ssh `whoami`@relengwebadm.private.scl3.mozilla.com<br />
sudo su -<br />
export ME=jwood<br />
export ZIP=mobile_tp4.zip<br />
chmod 644 /home/$ME/$ZIP<br />
sha1sum /home/$ME/$ZIP<br />
cd /data/releng/src/talos-remote/www/<br />
unzip /home/$ME/$ZIP ./<br />
# finally update the web heads<br />
cd ../<br />
./update<br />
<br />
=== Tp5n.zip ===<br />
<br />
export URL=http://people.mozilla.org/~jmaher/taloszips/zips/tp5n.zip<br />
export TALOS_ZIP=`basename $URL`<br />
wget $URL<br />
scp ${TALOS_ZIP} `whoami`@relengwebadm.private.scl3.mozilla.com:.<br />
<br />
# Connect to root @ relengwebadm<br />
ssh `whoami`@relengwebadm.private.scl3.mozilla.com<br />
sudo su -<br />
export ME=jwood ## BE SURE TO CHANGE<br />
export ZIP=tp5n.zip<br />
export BUG=1288135 ## BE SURE TO CHNAGE<br />
chmod 644 /home/$ME/$ZIP<br />
sha1sum /home/$ME/$ZIP<br />
cd /mnt/netapp/relengweb/talos-bundles/zips/<br />
cp ./tp5n.zip ./tp5n.before_bug_$BUG.zip<br />
mv /home/$ME/$ZIP ./ # YES to overwrite here<br />
<br />
= Ganglia =<br />
* if you see that a host is reporting to ganglia in an incorrect manner it might just take this to fix it (e.g. {{bug|674233}}):<br />
switch to root, service gmond restart<br />
<br />
= Queue Directories =<br />
* [https://wiki.mozilla.org/ReleaseEngineering/Queue_directories Queue directories]<br />
<br />
If you see this in #build:<br />
<br />
<nagios-sjc1> [54] buildbot-master12.build.scl1:Command Queue is CRITICAL: 4 dead items<br />
<br />
It means that there are items in the "dead" queue for the given master. You need to look at the logs and fix any underlying issue and then retry the command by moving *only* the json file over to the "new" queue. See the [https://wiki.mozilla.org/ReleaseEngineering/Queue_directories Queue directories] wiki page for details.<br />
= Cruncher = <br />
If you get an alert about cruncher running out of space it might be a sendmail issue (backed up emails taking up too much space and not getting sent out):<br />
<br />
<nagios-sjc1> [07] cruncher.build.sjc1:disk - / is WARNING: DISK WARNING - free space: / 384 MB (5% inode=93%):<br />
As root:<br />
du -s -h /var/spool/*<br />
# confirm that mqueue or clientmqueue is the oversized culprit<br />
# stop sendmail, clean out the queues, restart sendmail<br />
/etc/init.d/sendmail stop<br />
rm -rf /var/spool/clientmqueue/*<br />
rm -rf /var/spool/mqueue/*<br />
/etc/init.d/sendmail start<br />
<br />
= hg<->git conversion =<br />
This is a production system RelEng built, but has not yet transitioned to full IT operation. As a production system, it is supported 24x7x365 - escalate to IT oncall (who can page) as needed.<br />
<br />
We'll get problem reports from 2 sources:<br />
* via email from vcs2vcs user to release+vcs2vcs@m.c - see [[ReleaseEngineering/How_To/Process_release_email|email handling]] instructions for those.<br />
* via a bug report for a customer visible condition - this should only be if there is a new error we aren't detecting ourselves. See the resources below and/or page hwine.<br />
<br />
Documentation for this system:<br />
* [http://people.mozilla.com/~hwine/tmp/vcs2vcs/ recent docs] ([http://people.mozilla.org/~hwine/tmp/vcs2vcs/trouble_shooting.html troubleshooting])<br />
* source code: http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-tools/<br />
* config files: http://hg.mozilla.org/users/hwine_mozilla.com/repo-sync-configs/<br />
<br />
All services run as user vcs2vcs on one of the following hosts (as of 2013-01-07): github-sync1-dev.dmz.scl3.mozilla.com, github-sync1.dmz.scl3.mozilla.com, github-sync2.dmz.scl3.mozilla.com, github-sync3.dmz.scl3.mozilla.com.<br />
<br />
== Handling alert_major_errors ==<br />
<br />
# SSH as yourself to the hostname in the 'from' address of the alert_major_errors email.<br />
$ ssh yourname@github-sync3.dmz.scl3.mozilla.com<br />
$ sudo su - vcs2vcs<br />
$ cd etc<br />
# find the repo name that vcs2vcs is complaining about. For example:<br />
$ grep releases-mozilla-central-no-cvs *<br />
job02_cmds:# "hg:$HOME/repos/releases-mozilla-central-no-cvs" "github"<br />
# discover where that job runs<br />
$ grep job02 status<br />
job02_cmds,github-sync3.dmz.scl3.mozilla.com,m-c w/o cvs as used by b2g<br />
# connect to that host the same as we did above (if not already connected)<br />
# then<br />
$ cd logs/job02 # same job as above<br />
$ show_update_errors update.log<br />
# Note: the command exit code precedes the command itself<br />
# eg. ...;255;hg --cwd...<br />
<br />
Continue with instructions [http://people.mozilla.com/~hwine/tmp/vcs2vcs/trouble_shooting.html#repo-copy-not-updating here].<br />
<br />
= disable/re-enable aurora updates =<br />
Take care of by the person doing the final release since merge day activities are on the Monday before the release.<br />
<br />
= Upload =<br />
== Python packages ==<br />
{{warning|Mozharness no longer uses packages from the PuppetAgain repositories! Instead, it uses http://pypi.pub.build.mozilla.org/pub and http://pypi.pvt.build.mozilla.org/pub, both served from the same directory.}}<br />
<br />
See https://hg.mozilla.org/build/braindump/file/default/utils/publish_package_our_pypi.sh<br />
<br />
Download the tool above, and then run this from your local machine:<br />
publish_package_our_pypi.sh <your_python_package.tar.gz><br />
<br />
== How to upload to Tooltool ==<br />
<br />
See [[ReleaseEngineering/Applications/Tooltool#How_to_upload_to_tooltool]]<br />
<br />
== How to enable a user to run Tooltool uploads ==<br />
<br />
See [[ReleaseEngineering/Applications/Tooltool#How_to_enable_a_user_to_run_tooltool_uploads]].<br />
<br />
== How to upload Talos ZIPs ==<br />
See [[ReleaseEngineering:Buildduty:Other_Duties#How_to_update_the_talos_zips|How to update the talos zips]].<br />
<br />
== How to add NPM packages ==<br />
See [[ReleaseEngineering/How To/Mirror NPM Packages]]<br />
<br />
== How to upload new xre.zip files for B2G tests ==<br />
* You can use the script at https://github.com/jonallengriffin/xregen/blob/master/xre_gen.sh to generate a new xre.zip for any OS, based on a gecko release version. If you need an xre.zip for which there are only nightly builds (but not release builds), you can use xre.zip as a guide for how to construct the package, but you'll need to do it manually.<br />
* After you create the xre.zip's (currently needed for linux64 and macosx64), upload them to tooltool, and then update the relevant mozharness config files, currently:<br />
** b2g/gaia_unit_production_config.py<br />
** b2g/gaia_integration_config.py<br />
** marionette/gaia_ui_test_prod_config.py<br />
<br />
= buildbot master age =<br />
The memory used by buildbot master gradually increases over time. If not restarted, the masters can start to slowdown. This can affect job performance. To counteract this, we try to gracefully restart the buildbot masters every 4-6 weeks. We have nagios alerts in place to remind us to do this: <br />
"[4839] buildbot-master111.bb.releng.scl3.mozilla.com:buildbot masters age is �7WARNING���: \<br />
ELAPSED WARNING: 1 warn out of 1 process with command name buildbot \<br />
(http://m.mozilla.org/buildbot+masters+age)"<br />
<br />
We usually restart the masters on Sunday when load is the lowest so that it takes the least time for jobs to drain from each master as they restart. <br />
<br />
If the nagios alert is going off and it's not Sunday, or something else is preventing you from gracefully restarting the masters immediately (release-in-progress, etc), it is safe to downtime the alert for a few days until you will have time to deal with it.<br />
<br />
When you *are* ready to gracefully restart the masters, find a VPN-connected machine with a stable connection -- the script can take _many_ hours to iterate through all the masters -- and run the following script: <br />
<br />
https://github.com/ccooper/build-tools/blob/master/buildfarm/maintenance/restart_masters.py<br />
<br />
Unless you're coop, you'll need to edit some variables in the script to point to your own access credentials. <br />
<br />
At some point, we should automate the running of this script, possibly every Sunday.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Mirror_Releases_on_dev-stage01&diff=1175437ReleaseEngineering/How To/Mirror Releases on dev-stage012017-07-11T01:17:34Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Mirror Releases on dev-stage01 to ReleaseEngineering/Archive/Mirror Releases on dev-stage01</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Mirror Releases on dev-stage01]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Mirror_Releases_on_dev-stage01&diff=1175436ReleaseEngineering/Archive/Mirror Releases on dev-stage012017-07-11T01:17:25Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Mirror Releases on dev-stage01 to ReleaseEngineering/Archive/Mirror Releases on dev-stage01</p>
<hr />
<div>= This page is obsolete =<br />
<br />
by default, every request to dev-stage01 is served using the content from http://stage.mozilla.org (via a proxy pass directive) unless the requested resource is present locally.<br />
<br />
Here is the apache rewrite rule that makes it possible (from /etc/httpd/conf.d/release-candidates.conf):<br />
<pre><br />
# general mechanism<br />
RewriteEngine on<br />
<br />
# Do not proxy index.html pages. they are "virtual" and don't exist on disk<br />
RewriteCond %{REQUEST_FILENAME} !-f<br />
RewriteCond %{REQUEST_FILENAME} !-d<br />
RewriteRule ^.*index\.html - [L]<br />
<br />
RewriteCond %{REQUEST_FILENAME} !-f<br />
RewriteCond %{REQUEST_FILENAME} !-d<br />
RewriteRule ^(.+) http://stage.mozilla.org$1 [L]<br />
</pre><br />
<br />
no need to add your releases/candidates rules anymore.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Mirror_Releases_on_dev-stage01&diff=1175435ReleaseEngineering/Archive/Mirror Releases on dev-stage012017-07-11T01:17:13Z<p>Asasaki: Remove the how to header, add obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
by default, every request to dev-stage01 is served using the content from http://stage.mozilla.org (via a proxy pass directive) unless the requested resource is present locally.<br />
<br />
Here is the apache rewrite rule that makes it possible (from /etc/httpd/conf.d/release-candidates.conf):<br />
<pre><br />
# general mechanism<br />
RewriteEngine on<br />
<br />
# Do not proxy index.html pages. they are "virtual" and don't exist on disk<br />
RewriteCond %{REQUEST_FILENAME} !-f<br />
RewriteCond %{REQUEST_FILENAME} !-d<br />
RewriteRule ^.*index\.html - [L]<br />
<br />
RewriteCond %{REQUEST_FILENAME} !-f<br />
RewriteCond %{REQUEST_FILENAME} !-d<br />
RewriteRule ^(.+) http://stage.mozilla.org$1 [L]<br />
</pre><br />
<br />
no need to add your releases/candidates rules anymore.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Update_The_Foxfooding_Program_IMEI_Whitelist&diff=1175434ReleaseEngineering/How To/Update The Foxfooding Program IMEI Whitelist2017-07-11T01:16:18Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update The Foxfooding Program IMEI Whitelist to ReleaseEngineering/Archive/Update The Foxfooding Program IMEI Whitelist</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Update The Foxfooding Program IMEI Whitelist]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_The_Foxfooding_Program_IMEI_Whitelist&diff=1175433ReleaseEngineering/Archive/Update The Foxfooding Program IMEI Whitelist2017-07-11T01:16:08Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update The Foxfooding Program IMEI Whitelist to ReleaseEngineering/Archive/Update The Foxfooding Program IMEI Whitelist</p>
<hr />
<div>= This page is obsolete =<br />
<br />
The Foxfooding Program IMEI Whitelist as a listed of hashed IMEIs of Foxfooding devices that are allowed to receive updates on the "foxfood" channel. This list is maintained in Balrog as a strucuted piece of JSON. It was initially created as part of {{bug|1207313}}.<br />
<br />
To make changes to it, follow these instructions:<br />
<ol><br />
<li>Determine which IMEI(s) need changes. IMEIs are hashed with SHA512, so you'll need the hashed version of each IMEI before you get started. To calculate this, you can use the "sha512sum" command (Linux) or "shasum -a 512" (OS X). Eg:</li><br />
<pre><br />
$ echo -n "123456789" | sha512sum<br />
ff3245abe317049ed1b8aa7aa2f4c4dcb8bf86f083ed67eb26b43e2fbe3ba8fdf759f9e2f46fcf2a06c2dfeddf0cedcd41a68034cd618b880785b34f759d1a69 -<br />
<br />
$ echo -n "123456789" | shasum -a 512<br />
ff3245abe317049ed1b8aa7aa2f4c4dcb8bf86f083ed67eb26b43e2fbe3ba8fdf759f9e2f46fcf2a06c2dfeddf0cedcd41a68034cd618b880785b34f759d1a69 -<br />
</pre><br />
<li>Locate [https://aus4-admin-dev.allizom.org/releases#B2G-Foxfood-IMEI-Whitelist The "B2G-Foxfood-IMEI-Whitelist" blob] in Balrog's admin UI.</li><br />
<li>Click the "Download" link, save the file to your computer:</li><br />
[[File:Imei whitelist release.png]]<br />
<li>Open up the saved file in a text editor</li><br />
<li>Edit the file as needed</li><br />
<ul><br />
<li>If adding a new IMEI to the list:</li><br />
<ul><br />
<li>Copy and paste the first block, then edit the IMEI. For example, let's add "abcdef9876" to this whitelist:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
<li> Which now becomes:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef9876"<br />
},<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
</ul><br />
<li>If removing an IMEI:</li><br />
<ul><br />
<li>Remove its block entirely. For example, let's remove "fedcba123456" from this whitelist:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
<li>Which now becomes:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
</ul><br />
</ul><br />
<li>When you have completed all of your edits, it's a good idea to validate that the JSON formatting is correct. You can do this by copying and pasting the new contents into [http://jsonlint.com/ an online JSON validator].</i><br />
<li>Now you're ready to upload the new whitelist to Balrog. You'll need to [https://aus4-admin-dev.allizom.org/releases#B2G-Foxfood-IMEI-Whitelist find it in the admin UI] again. Click the "Update" button, then "Browse" (and choose the file you just edited locally), then click "Save":</li><br />
[[File:Imei upload.png]]<br />
<li>If you get this dialog, the whitelist format is incorrect, otherwise the whitelist has been updated:</li><br />
[[File:Balrog_form_submission_error.png]]<br />
<br />
= Notes =<br />
* To update the whitelist, the user needs permission "<code>/releases/:name</code>" with the "<code>{"product":"B2G"}</code> option.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_The_Foxfooding_Program_IMEI_Whitelist&diff=1175432ReleaseEngineering/Archive/Update The Foxfooding Program IMEI Whitelist2017-07-11T01:15:55Z<p>Asasaki: obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
The Foxfooding Program IMEI Whitelist as a listed of hashed IMEIs of Foxfooding devices that are allowed to receive updates on the "foxfood" channel. This list is maintained in Balrog as a strucuted piece of JSON. It was initially created as part of {{bug|1207313}}.<br />
<br />
To make changes to it, follow these instructions:<br />
<ol><br />
<li>Determine which IMEI(s) need changes. IMEIs are hashed with SHA512, so you'll need the hashed version of each IMEI before you get started. To calculate this, you can use the "sha512sum" command (Linux) or "shasum -a 512" (OS X). Eg:</li><br />
<pre><br />
$ echo -n "123456789" | sha512sum<br />
ff3245abe317049ed1b8aa7aa2f4c4dcb8bf86f083ed67eb26b43e2fbe3ba8fdf759f9e2f46fcf2a06c2dfeddf0cedcd41a68034cd618b880785b34f759d1a69 -<br />
<br />
$ echo -n "123456789" | shasum -a 512<br />
ff3245abe317049ed1b8aa7aa2f4c4dcb8bf86f083ed67eb26b43e2fbe3ba8fdf759f9e2f46fcf2a06c2dfeddf0cedcd41a68034cd618b880785b34f759d1a69 -<br />
</pre><br />
<li>Locate [https://aus4-admin-dev.allizom.org/releases#B2G-Foxfood-IMEI-Whitelist The "B2G-Foxfood-IMEI-Whitelist" blob] in Balrog's admin UI.</li><br />
<li>Click the "Download" link, save the file to your computer:</li><br />
[[File:Imei whitelist release.png]]<br />
<li>Open up the saved file in a text editor</li><br />
<li>Edit the file as needed</li><br />
<ul><br />
<li>If adding a new IMEI to the list:</li><br />
<ul><br />
<li>Copy and paste the first block, then edit the IMEI. For example, let's add "abcdef9876" to this whitelist:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
<li> Which now becomes:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef9876"<br />
},<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
</ul><br />
<li>If removing an IMEI:</li><br />
<ul><br />
<li>Remove its block entirely. For example, let's remove "fedcba123456" from this whitelist:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
<li>Which now becomes:</li><br />
<pre><br />
{<br />
"whitelist": [<br />
{<br />
"imei": "abcdef123546"<br />
},<br />
{<br />
"imei": "fedcba654321"<br />
}<br />
],<br />
"name": "B2G-Foxfood-IMEI-Whitelist",<br />
"schema_version": 3000<br />
}<br />
</pre><br />
</ul><br />
</ul><br />
<li>When you have completed all of your edits, it's a good idea to validate that the JSON formatting is correct. You can do this by copying and pasting the new contents into [http://jsonlint.com/ an online JSON validator].</i><br />
<li>Now you're ready to upload the new whitelist to Balrog. You'll need to [https://aus4-admin-dev.allizom.org/releases#B2G-Foxfood-IMEI-Whitelist find it in the admin UI] again. Click the "Update" button, then "Browse" (and choose the file you just edited locally), then click "Save":</li><br />
[[File:Imei upload.png]]<br />
<li>If you get this dialog, the whitelist format is incorrect, otherwise the whitelist has been updated:</li><br />
[[File:Balrog_form_submission_error.png]]<br />
<br />
= Notes =<br />
* To update the whitelist, the user needs permission "<code>/releases/:name</code>" with the "<code>{"product":"B2G"}</code> option.</div>Asasakihttps://wiki.mozilla.org/index.php?title=Talk:ReleaseEngineering/How_To/Android_Tegras&diff=1175428Talk:ReleaseEngineering/How To/Android Tegras2017-07-11T01:02:10Z<p>Asasaki: Asasaki moved page Talk:ReleaseEngineering/How To/Android Tegras to Talk:ReleaseEngineering/Archive/Android Tegras</p>
<hr />
<div>#REDIRECT [[Talk:ReleaseEngineering/Archive/Android Tegras]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Enable_or_Disable_Updates_on_Aurora&diff=1175429ReleaseEngineering/How To/Enable or Disable Updates on Aurora2017-07-11T01:02:10Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Enable or Disable Updates on Aurora to ReleaseEngineering/Archive/Enable or Disable Updates on Aurora</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Enable or Disable Updates on Aurora]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=Talk:ReleaseEngineering/Archive/Android_Tegras&diff=1175427Talk:ReleaseEngineering/Archive/Android Tegras2017-07-11T01:02:02Z<p>Asasaki: Asasaki moved page Talk:ReleaseEngineering/How To/Android Tegras to Talk:ReleaseEngineering/Archive/Android Tegras</p>
<hr />
<div>= what bhearsum did to get a bunch of tegras online =<br />
<br />
I attacked the pool of broken/dead Tegras this week, and with a lot of guidance from Callek, managed to get a bunch of them back online. The Tegra wiki page (https://wiki.mozilla.org/ReleaseEngineering:How_To:Android_Tegras) isn't very helpful in terms of mapping "state it's in" -> "action i need to take", so I wanted to let you all know the simple steps I took:<br />
<br />
# Look for Tegras with alerts on http://admin1.infra.scl1.mozilla.com/nagios/cgi-bin/status.cgi?host=all&servicestatustypes=28&hoststatustypes=15&serviceprops=270346<br />
# Find the Tegra on http://mobile-dashboard1.build.mtv1.mozilla.com/tegras/<br />
# Click the "tegra-xxx" link to find the Tegra's Buildbot page<br />
# If the Tegra is offline, try to PDU reboot it (https://wiki.mozilla.org/ReleaseEngineering:How_To:Android_Tegras#Reboot_a_Tegra_through_the_PDU)<br />
# If the Tegra isn't online 30min later, open its bug and block it against the "tegra-recovery" bug. You may need to file one or both of these.<br />
# If that doesn't work, talk to Callek ;).<br />
<br />
And that's it! More than half the Tegras I touched came back online either through the PDU reboot or IT recovery. I implore you all to keep on top of Tegras when you're on buildduty - it's not as hard as it seems.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Enable_or_Disable_Updates_on_Aurora&diff=1175426ReleaseEngineering/Archive/Enable or Disable Updates on Aurora2017-07-11T01:01:56Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Enable or Disable Updates on Aurora to ReleaseEngineering/Archive/Enable or Disable Updates on Aurora</p>
<hr />
<div>= This page is obsolete =<br />
<br />
When Nightly merges into Aurora every 6 weeks we lock Aurora updates at a specific old version for a period of time (days to a week) while QA runs some tests. Once their tests have passed, we re-enable updates. We're also occaisonly asked to disable updates temporarily for other reasons. This document describes how to do both of these things.<br />
<br />
Note the magic rule ids below. These correspond to ids of rows in the "rules" table of Balrog. If we fix {{bug|1067402}} we can pass more intelligable values here.<br />
<br />
= Disabling Updates =<br />
NOTE: Disabling no longer has to be done by hand during uplifts. The uplift script does it.<br />
<br />
= Enabling Updates =<br />
Unlike disabling, Firefox and Fennec aren't always re-enabled at the same time. Make sure you are connected to releng VPN.<br />
<br />
'''NOTE''': You may not be able to run these scripts unless you have a linux laptop. See {{bug|1151633}} for details and workarounds.<br />
<br />
== Fennec ==<br />
<pre><br />
cd /tmp<br />
rm -rf tools<br />
hg clone https://hg.mozilla.org/build/tools<br />
cd tools/scripts/updates<br />
scp cltbld@buildbot-master81.bb.releng.scl3.mozilla.com:/builds/buildbot/build_scheduler/master/BuildSlaves.py oauth.txt<br />
# Run with dry run first, sanity check the "Would've unlocked" lines.<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 8 -n unlock<br />
# Run without dry run to unlock the updates<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 8 unlock<br />
</pre><br />
<br />
== Firefox ==<br />
<pre><br />
cd /tmp<br />
rm -rf tools<br />
hg clone https://hg.mozilla.org/build/tools<br />
cd tools/scripts/updates<br />
scp cltbld@buildbot-master81.bb.releng.scl3.mozilla.com:/builds/buildbot/build_scheduler/master/BuildSlaves.py oauth.txt<br />
# Run with dry run first, sanity check the "Would've unlocked" lines.<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 10 -n unlock<br />
# Run without dry run to unlock the updates<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 10 unlock<br />
</pre><br />
<br />
== Cleanup ==<br />
<pre><br />
# preferably with srm or equivalent<br />
srm oauth.txt<br />
</pre><br />
<br />
== Update bouncer ==<br />
When re-enable updates for Aurora, update the following bouncer locations to use the new version for aurora:<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=2006 firefox-aurora-latest]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=3686 firefox-aurora-latest-ssl]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=3685 firefox-aurora-latest-l10n]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=6510 firefox-aurora-latest-l10n-ssl]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=2061 firefox-aurora-stub]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=6511 firefox-aurora-stub-l10n]<br />
<br />
NB: it is expected that the two stub products have a win and win64 location which both point to the same location. We don't have a win64 stub installer, instead the mislabeled 32bit stub selects the correct full installer at runtime.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Android_Tegras&diff=1175425ReleaseEngineering/How To/Android Tegras2017-07-11T01:01:55Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Android Tegras to ReleaseEngineering/Archive/Android Tegras</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Android Tegras]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Android_Tegras&diff=1175424ReleaseEngineering/Archive/Android Tegras2017-07-11T01:01:46Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Android Tegras to ReleaseEngineering/Archive/Android Tegras</p>
<hr />
<div>This page is obsolete.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Enable_or_Disable_Updates_on_Aurora&diff=1175423ReleaseEngineering/Archive/Enable or Disable Updates on Aurora2017-07-11T01:01:38Z<p>Asasaki: Remove the how to header, add obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
When Nightly merges into Aurora every 6 weeks we lock Aurora updates at a specific old version for a period of time (days to a week) while QA runs some tests. Once their tests have passed, we re-enable updates. We're also occaisonly asked to disable updates temporarily for other reasons. This document describes how to do both of these things.<br />
<br />
Note the magic rule ids below. These correspond to ids of rows in the "rules" table of Balrog. If we fix {{bug|1067402}} we can pass more intelligable values here.<br />
<br />
= Disabling Updates =<br />
NOTE: Disabling no longer has to be done by hand during uplifts. The uplift script does it.<br />
<br />
= Enabling Updates =<br />
Unlike disabling, Firefox and Fennec aren't always re-enabled at the same time. Make sure you are connected to releng VPN.<br />
<br />
'''NOTE''': You may not be able to run these scripts unless you have a linux laptop. See {{bug|1151633}} for details and workarounds.<br />
<br />
== Fennec ==<br />
<pre><br />
cd /tmp<br />
rm -rf tools<br />
hg clone https://hg.mozilla.org/build/tools<br />
cd tools/scripts/updates<br />
scp cltbld@buildbot-master81.bb.releng.scl3.mozilla.com:/builds/buildbot/build_scheduler/master/BuildSlaves.py oauth.txt<br />
# Run with dry run first, sanity check the "Would've unlocked" lines.<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 8 -n unlock<br />
# Run without dry run to unlock the updates<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 8 unlock<br />
</pre><br />
<br />
== Firefox ==<br />
<pre><br />
cd /tmp<br />
rm -rf tools<br />
hg clone https://hg.mozilla.org/build/tools<br />
cd tools/scripts/updates<br />
scp cltbld@buildbot-master81.bb.releng.scl3.mozilla.com:/builds/buildbot/build_scheduler/master/BuildSlaves.py oauth.txt<br />
# Run with dry run first, sanity check the "Would've unlocked" lines.<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 10 -n unlock<br />
# Run without dry run to unlock the updates<br />
python2.7 balrog-nightly-locker.py -a https://aus4-admin.mozilla.org/api -c oauth.txt -u ffxbld -r 10 unlock<br />
</pre><br />
<br />
== Cleanup ==<br />
<pre><br />
# preferably with srm or equivalent<br />
srm oauth.txt<br />
</pre><br />
<br />
== Update bouncer ==<br />
When re-enable updates for Aurora, update the following bouncer locations to use the new version for aurora:<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=2006 firefox-aurora-latest]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=3686 firefox-aurora-latest-ssl]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=3685 firefox-aurora-latest-l10n]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=6510 firefox-aurora-latest-l10n-ssl]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=2061 firefox-aurora-stub]<br />
* [https://bounceradmin.mozilla.com/admin/mirror/location/?product__id__exact=6511 firefox-aurora-stub-l10n]<br />
<br />
NB: it is expected that the two stub products have a win and win64 location which both point to the same location. We don't have a win64 stub installer, instead the mislabeled 32bit stub selects the correct full installer at runtime.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Android_Tegras&diff=1175422ReleaseEngineering/Archive/Android Tegras2017-07-11T01:01:21Z<p>Asasaki: obsolete header</p>
<hr />
<div>This page is obsolete.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Update_a_B2G_snapshot&diff=1175421ReleaseEngineering/How To/Update a B2G snapshot2017-07-11T00:59:57Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update a B2G snapshot to ReleaseEngineering/Archive/Update a B2G snapshot</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Update a B2G snapshot]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_a_B2G_snapshot&diff=1175420ReleaseEngineering/Archive/Update a B2G snapshot2017-07-11T00:59:48Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update a B2G snapshot to ReleaseEngineering/Archive/Update a B2G snapshot</p>
<hr />
<div>This page is obsolete. We no longer generate static b2g snapshots.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_a_B2G_snapshot&diff=1175419ReleaseEngineering/Archive/Update a B2G snapshot2017-07-11T00:59:35Z<p>Asasaki: Remove the how to header</p>
<hr />
<div>This page is obsolete. We no longer generate static b2g snapshots.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Update_B2G_Blobs&diff=1175418ReleaseEngineering/How To/Update B2G Blobs2017-07-11T00:59:22Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update B2G Blobs to ReleaseEngineering/Archive/Update B2G Blobs</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Update B2G Blobs]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_B2G_Blobs&diff=1175417ReleaseEngineering/Archive/Update B2G Blobs2017-07-11T00:59:13Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Update B2G Blobs to ReleaseEngineering/Archive/Update B2G Blobs</p>
<hr />
<div>= This page is obsolete =<br />
<br />
* [https://wiki.mozilla.org/ReleaseEngineering:Buildduty:Other_Duties#How_to_upload_to_Tooltool Upload the file to tooltool]<br />
* Update your local clone of https://hg.mozilla.org/integration/b2g-inbound/<br />
* Edit the appropriate device config. eg. b2g/config/hamachi/releng-hamachi.tt<br />
* Change 'size' and 'digest' of the file being updated.<br />
* Attach a patch to the bug for review<br />
* Once reviewed, land the patch on b2g-inbound<br />
* Watch for a successful build, then uplift to the relevant branch(es) mentioned in the bug, specifying a=NPOTB<br />
** As an alternative to uplifting the patch yourself, set a [checkin-needed-<branchname>] to flag the Sheriffs to do the uplift for you.<br />
<br />
Note: the backup-helix tarball needs to be repacked such that the top level directory changes from backup-helix/ to backup-ics/ [https://bugzilla.mozilla.org/show_bug.cgi?id=939315#c3][https://bugzilla.mozilla.org/show_bug.cgi?id=917642#c59]. Use the [http://hg.mozilla.org/build/braindump/file/27ded01ad371/utils/reparent-tarball reparent-tarball] script to automate this.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Update_B2G_Blobs&diff=1175416ReleaseEngineering/Archive/Update B2G Blobs2017-07-11T00:59:00Z<p>Asasaki: Remove the how to header, add obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
* [https://wiki.mozilla.org/ReleaseEngineering:Buildduty:Other_Duties#How_to_upload_to_Tooltool Upload the file to tooltool]<br />
* Update your local clone of https://hg.mozilla.org/integration/b2g-inbound/<br />
* Edit the appropriate device config. eg. b2g/config/hamachi/releng-hamachi.tt<br />
* Change 'size' and 'digest' of the file being updated.<br />
* Attach a patch to the bug for review<br />
* Once reviewed, land the patch on b2g-inbound<br />
* Watch for a successful build, then uplift to the relevant branch(es) mentioned in the bug, specifying a=NPOTB<br />
** As an alternative to uplifting the patch yourself, set a [checkin-needed-<branchname>] to flag the Sheriffs to do the uplift for you.<br />
<br />
Note: the backup-helix tarball needs to be repacked such that the top level directory changes from backup-helix/ to backup-ics/ [https://bugzilla.mozilla.org/show_bug.cgi?id=939315#c3][https://bugzilla.mozilla.org/show_bug.cgi?id=917642#c59]. Use the [http://hg.mozilla.org/build/braindump/file/27ded01ad371/utils/reparent-tarball reparent-tarball] script to automate this.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Tag_a_B2G_Release&diff=1175415ReleaseEngineering/How To/Tag a B2G Release2017-07-11T00:58:26Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Tag a B2G Release to ReleaseEngineering/Archive/Tag a B2G Release</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Tag a B2G Release]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Tag_a_B2G_Release&diff=1175414ReleaseEngineering/Archive/Tag a B2G Release2017-07-11T00:58:16Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Tag a B2G Release to ReleaseEngineering/Archive/Tag a B2G Release</p>
<hr />
<div>= This page is obsolete =<br />
<br />
This is done as a manual step done when B2G reldrivers say to tag.<br />
<br />
<pre><br />
cd src<br />
git clone git@github.com:mozilla-b2g/gaia.git<br />
cd gaia<br />
git log | more<br />
git tag B2G_1_0_0_20130115070201 a03f7b532e9998e646d55f93a0fc03a04d7ca7d9<br />
git push --dry-run --tags<br />
git show B2G_1_0_0_20130115070201<br />
git push --tags<br />
<br />
hg clone http://hg.mozilla.org/releases/mozilla-b2g18<br />
cd mozilla-b2g18/<br />
hg tag -r 67503cae6a5a B2G_1_0_0_20130115070201 -m "comments" # see notes<br />
hg out --patch<br />
hg push<br />
</pre><br />
<br />
Notes:<br />
* in your HG tag commit, always include the magic keywords "DONTBUILD", "CLOSEDTREE" and "a=NPOTB" to ensure we can easily merge them onto other hg branches during the switching period<br />
* tags will take approx 20 min to propagate to git.m.o<br />
* only hg tags starting with 'B2G' will be propagated</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Tag_a_B2G_Release&diff=1175413ReleaseEngineering/Archive/Tag a B2G Release2017-07-11T00:58:00Z<p>Asasaki: obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
This is done as a manual step done when B2G reldrivers say to tag.<br />
<br />
<pre><br />
cd src<br />
git clone git@github.com:mozilla-b2g/gaia.git<br />
cd gaia<br />
git log | more<br />
git tag B2G_1_0_0_20130115070201 a03f7b532e9998e646d55f93a0fc03a04d7ca7d9<br />
git push --dry-run --tags<br />
git show B2G_1_0_0_20130115070201<br />
git push --tags<br />
<br />
hg clone http://hg.mozilla.org/releases/mozilla-b2g18<br />
cd mozilla-b2g18/<br />
hg tag -r 67503cae6a5a B2G_1_0_0_20130115070201 -m "comments" # see notes<br />
hg out --patch<br />
hg push<br />
</pre><br />
<br />
Notes:<br />
* in your HG tag commit, always include the magic keywords "DONTBUILD", "CLOSEDTREE" and "a=NPOTB" to ensure we can easily merge them onto other hg branches during the switching period<br />
* tags will take approx 20 min to propagate to git.m.o<br />
* only hg tags starting with 'B2G' will be propagated</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Adjust_B2G_Update_Channels_on_Merge_Day&diff=1175412ReleaseEngineering/How To/Adjust B2G Update Channels on Merge Day2017-07-11T00:57:33Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Adjust B2G Update Channels on Merge Day to ReleaseEngineering/Archive/Adjust B2G Update Channels on Merge Day</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Adjust B2G Update Channels on Merge Day]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Adjust_B2G_Update_Channels_on_Merge_Day&diff=1175411ReleaseEngineering/Archive/Adjust B2G Update Channels on Merge Day2017-07-11T00:57:24Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Adjust B2G Update Channels on Merge Day to ReleaseEngineering/Archive/Adjust B2G Update Channels on Merge Day</p>
<hr />
<div>= This page is obsolete =<br />
<br />
When Nightly merges into Aurora every 6 weeks we lock Aurora updates at a specific old version for a period of time (days to a week) while QA runs some tests. Once their tests have passed, we re-enable updates. This document describes how to do both of these things.<br />
<br />
= Central will become an odd-numbered Gecko version =<br />
* Repoint B2G Aurora updates at Aurora builds:<br />
*# Go to [https://aus4-admin.mozilla.org/rules.html the Balrog Admin interface's rules page].<br />
*# Find the rule that has "B2G" for the product and "aurora" for the channel<br />
*# Change the "Mapping" for that rule to "B2G-mozilla-aurora-nightly-latest"<br />
*# Scroll to the right and click "Update" to make the change.<br />
<br />
= Central will become an even-numbered Gecko version =<br />
* Point B2G Aurora updates at the newly created mozilla-b2gXX builds:<br />
*# Go to [https://aus4-admin.mozilla.org/rules.html the Balrog Admin interface's rules page].<br />
*# Find the rule that has "B2G" for the product and "aurora" for the channel<br />
*# Change the "Mapping" for that rule to "B2G-mozilla-b2gXX_vX_X-nightly-latest" - for example, "B2G-mozilla-b2g32_v2_0-nightly-latest" was used on the merge day that created the mozilla-b2g32_v2_0 branch.<br />
*# Scroll to the right and click "Update" to make the change.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Adjust_B2G_Update_Channels_on_Merge_Day&diff=1175410ReleaseEngineering/Archive/Adjust B2G Update Channels on Merge Day2017-07-11T00:57:07Z<p>Asasaki: Remove the how to header, add obsolete header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
When Nightly merges into Aurora every 6 weeks we lock Aurora updates at a specific old version for a period of time (days to a week) while QA runs some tests. Once their tests have passed, we re-enable updates. This document describes how to do both of these things.<br />
<br />
= Central will become an odd-numbered Gecko version =<br />
* Repoint B2G Aurora updates at Aurora builds:<br />
*# Go to [https://aus4-admin.mozilla.org/rules.html the Balrog Admin interface's rules page].<br />
*# Find the rule that has "B2G" for the product and "aurora" for the channel<br />
*# Change the "Mapping" for that rule to "B2G-mozilla-aurora-nightly-latest"<br />
*# Scroll to the right and click "Update" to make the change.<br />
<br />
= Central will become an even-numbered Gecko version =<br />
* Point B2G Aurora updates at the newly created mozilla-b2gXX builds:<br />
*# Go to [https://aus4-admin.mozilla.org/rules.html the Balrog Admin interface's rules page].<br />
*# Find the rule that has "B2G" for the product and "aurora" for the channel<br />
*# Change the "Mapping" for that rule to "B2G-mozilla-b2gXX_vX_X-nightly-latest" - for example, "B2G-mozilla-b2g32_v2_0-nightly-latest" was used on the merge day that created the mozilla-b2g32_v2_0 branch.<br />
*# Scroll to the right and click "Update" to make the change.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To&diff=1175409ReleaseEngineering/How To2017-07-11T00:55:52Z<p>Asasaki: remove b2g update channel intranet link</p>
<hr />
<div>This page lists release-engineering how-to guides - all subpages of this one, plus some external links.<br />
<br />
Please see also [[:Category:Release_Engineering_How_To]] for pages that have been flagged as having '''How To''' information in addition to other content. <br />
<br />
To add a new page, create a subpage of this one -- [[ReleaseEngineering/How To/Do Whatever..]]<br />
<br />
---<br />
Found <subpagecount /> How To's<br />
---<br />
<br />
<splist /><br />
<br />
==External How-To Links==<br />
* [https://mana.mozilla.org/wiki/display/IT/How+to+Change+Releng+Passwords How to Change Releng Passwords]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Reboot_A_Panda_Relay_Board&diff=1175408ReleaseEngineering/Archive/Reboot A Panda Relay Board2017-07-11T00:54:39Z<p>Asasaki: Remove the how to header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
If a Panda Relay Board fails to accept commands from mozpool but the web UI is still accessible, it can be reset remotely.<br />
<br />
Log in to the web UI with the relay board username and password (found in the relops password file)<br />
eg. http://panda-relay-001.p127.releng.scl3.mozilla.com/<br />
<br />
From the home page, click on the Reboot link under the Administration section on the left hand page. Then click the reboot button.<br />
<br />
This will reset the relay controller chip and should reestablish communications.</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Create_new_B2G_build&diff=1175407ReleaseEngineering/Archive/Create new B2G build2017-07-11T00:53:29Z<p>Asasaki: Remove the how to header</p>
<hr />
<div>= This page is obsolete =<br />
<br />
= Bugs =<br />
If we don't have one already, make sure there's a 'How to build X manually' bug filed. See e.g. {{bug|978888}} We'll also need to get any binary blobs from developers or QA at this point (this will be used in the tooltool manifest later)<br />
<br />
= In-tree files =<br />
In the gecko repo we will need a <br />
* sources.xml - a source manifest, which is a copy of the file in b2g-manifests updated to point at our mirror of repos<br />
* config.json - a device specific mozharness config<br />
* (maybe) a tooltool manifest - if we have binaries from a vendor to unpack at build time (config.json will refer to this manifest)<br />
<br />
These all live in b2g/config/<device>/. They need to land in the appropriate gecko before builds are enabled in buildbot.<br />
<br />
== Source manifest ==<br />
The in-tree manifest, sources.xml, is used to determine which sources to pull. To make sure these are being updated properly, ensure that the new device is added to the [http://hg.mozilla.org/build/mozharness/file/default/configs/b2g_bumper b2g_bumper configs].<br />
<br />
If this is a brand new device, or even running on a new branch, you may need to get new repositories mirrored. This command may be helpful to find these repositories:<br />
<br />
b2g_bumper.py -c b2g_bumper/<branch>.py --massage-manifests --checkout-manifests --no-write --device <newdevice><br />
<br />
You may need to adjust the mappings in 'repo_remote_mappings' in b2g_bumper/<branch>.py if you get a "Wasn't able to map" error.<br />
<br />
Otherwise, the script should either succeed or generate a bunch of "needs sync" output that should be copied into a bug like {{bug|1014102}}<br />
<br />
== mozharness config ==<br />
This specifies things like mock packages, environment, build targets, files to upload, where to get l10n from. See existing devices to get started.<br />
<br />
== tooltool manifest ==<br />
Typically used to unpack backup-<device>.tar.xz (binaries from vendors base image, provided by QA/developer), and other proprietary driver source/binaries. <br />
<br />
= buildbot changes =<br />
[http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/b2g_config.py b2g_config.py] will need adjusting for your device.<br />
<br />
= tbpl =<br />
File a bug like {{bug|984428}} to get the new device supported in tbpl<br />
<br />
= prior art =<br />
See {{bug|991393}} and {{bug|979450}} for recently added devices</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Reboot_A_Tegra_Remotely&diff=1175406ReleaseEngineering/Archive/Reboot A Tegra Remotely2017-07-11T00:52:38Z<p>Asasaki: obsolete header</p>
<hr />
<div><big>This page is obsolete</big></div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/How_To/Create_new_B2G_build&diff=1175405ReleaseEngineering/How To/Create new B2G build2017-07-11T00:52:19Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Create new B2G build to ReleaseEngineering/Archive/Create new B2G build: obsolete</p>
<hr />
<div>#REDIRECT [[ReleaseEngineering/Archive/Create new B2G build]]</div>Asasakihttps://wiki.mozilla.org/index.php?title=ReleaseEngineering/Archive/Create_new_B2G_build&diff=1175404ReleaseEngineering/Archive/Create new B2G build2017-07-11T00:52:10Z<p>Asasaki: Asasaki moved page ReleaseEngineering/How To/Create new B2G build to ReleaseEngineering/Archive/Create new B2G build: obsolete</p>
<hr />
<div>{{Release Engineering How To|Create new B2G build}}<br />
<br />
= This page is obsolete =<br />
<br />
= Bugs =<br />
If we don't have one already, make sure there's a 'How to build X manually' bug filed. See e.g. {{bug|978888}} We'll also need to get any binary blobs from developers or QA at this point (this will be used in the tooltool manifest later)<br />
<br />
= In-tree files =<br />
In the gecko repo we will need a <br />
* sources.xml - a source manifest, which is a copy of the file in b2g-manifests updated to point at our mirror of repos<br />
* config.json - a device specific mozharness config<br />
* (maybe) a tooltool manifest - if we have binaries from a vendor to unpack at build time (config.json will refer to this manifest)<br />
<br />
These all live in b2g/config/<device>/. They need to land in the appropriate gecko before builds are enabled in buildbot.<br />
<br />
== Source manifest ==<br />
The in-tree manifest, sources.xml, is used to determine which sources to pull. To make sure these are being updated properly, ensure that the new device is added to the [http://hg.mozilla.org/build/mozharness/file/default/configs/b2g_bumper b2g_bumper configs].<br />
<br />
If this is a brand new device, or even running on a new branch, you may need to get new repositories mirrored. This command may be helpful to find these repositories:<br />
<br />
b2g_bumper.py -c b2g_bumper/<branch>.py --massage-manifests --checkout-manifests --no-write --device <newdevice><br />
<br />
You may need to adjust the mappings in 'repo_remote_mappings' in b2g_bumper/<branch>.py if you get a "Wasn't able to map" error.<br />
<br />
Otherwise, the script should either succeed or generate a bunch of "needs sync" output that should be copied into a bug like {{bug|1014102}}<br />
<br />
== mozharness config ==<br />
This specifies things like mock packages, environment, build targets, files to upload, where to get l10n from. See existing devices to get started.<br />
<br />
== tooltool manifest ==<br />
Typically used to unpack backup-<device>.tar.xz (binaries from vendors base image, provided by QA/developer), and other proprietary driver source/binaries. <br />
<br />
= buildbot changes =<br />
[http://hg.mozilla.org/build/buildbot-configs/file/default/mozilla/b2g_config.py b2g_config.py] will need adjusting for your device.<br />
<br />
= tbpl =<br />
File a bug like {{bug|984428}} to get the new device supported in tbpl<br />
<br />
= prior art =<br />
See {{bug|991393}} and {{bug|979450}} for recently added devices</div>Asasaki