https://wiki.mozilla.org/api.php?action=feedcontributions&user=Mcote&feedformat=atomMozillaWiki - User contributions [en]2024-03-28T13:42:40ZUser contributionsMediaWiki 1.27.4https://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1204221Phabricator/FAQ2018-11-21T18:31:23Z<p>Mcote: /* Lando says "This diff does not have the proper author information uploaded to Phabricator", but I see an author on Phabricator. What's wrong? */ small formatting tweaks</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
Note that you will need to run "arc diff" again to update the patch even if you don't need to change it (e.g. the bustage was in an earlier commit). This is because Phabricator updates the revision after it lands but does not provide the necessary metadata that Lando needs. See {{bug|1489126}}.<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself. See {{bug|1475915}}.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== Command-line tools: moz-phab and arc ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the "contains arc fields" error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I see an author on Phabricator. What's wrong? ===<br />
<br />
There are a few reasons this could happen:<br />
<br />
* '''The revision was created via the Phabricator Web UI or via an unsupported client.'''<br />
** Use arcanist or moz-phab to submit the patch instead; see the [https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Mozilla Phabricator User Guide] for help.<br />
<br />
* '''The revision was created via arcanist or moz-phab, but the error still appears.'''<br />
** This can happen if you have not set an author email in your '''.hgrc''' file (or [https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup git config]). Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.<br />
<br />
* '''You are attempting to re-land a revision but [https://bugzilla.mozilla.org/show_bug.cgi?id=1489126 Bug 1489126] happens'''<br />
** This is an unfortunate bug that will be fixed in time, but for now you can get around this by reopening the revision on Phabricator and then resubmitting the revisions on your client. Follow the bug to see status updates.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator&diff=1204026Phabricator2018-11-16T18:25:26Z<p>Mcote: mozreview was shut down</p>
<hr />
<div>= Phabricator at Mozilla =<br />
<br />
Mozilla runs a Phabricator instance at https://phabricator.services.mozilla.com/, mainly for code review. It is currently the preferred solution for code review. [[EngineeringProductivity/Projects/MozReview|MozReview]] was decommissioned in 2018Q3, and Splinter will be decommissioned at some point in 2019.<br />
<br />
Also see [[Lando]], an automatic code-landing system integrated with Phabricator.<br />
<br />
Phabricator and Lando are maintained by the [[Engineering Workflow]] team.<br />
<br />
= Documentation =<br />
<br />
User documentation for Mozilla's Phabricator instance is available on [http://moz-conduit.readthedocs.io/en/latest/ Read the Docs]. There is also a [[/FAQ|user FAQ]] for Phabricator and Lando.<br />
<br />
= Operations and Testing =<br />
<br />
* [[Phabricator/UpgradeProcess|Upgrade process]]<br />
* [[Phabricator/TestPlan|Test plan]]<br />
<br />
= Background =<br />
== Why the change? ==<br />
<br />
Code review is a critical part of the Firefox engineering process but hasn’t changed much since Mozilla’s early days. Our home-developed tools have worked well for us but are increasingly dependent upon scarce resources to maintain, build and customize. Using our own tool, something that isn’t used by other organizations, also makes onboarding new people, staff and volunteers much more time-consuming than it needs to be.<br />
<br />
We are confident the short-term/immediate costs incurred—standing up a new tool, having to shift expectations and refactor workflows—will be more than paid back with surplus time and energy available for process automation (and later, with faster onboarding).<br />
<br />
== Why did we choose Differential? ==<br />
<br />
Differential, originally developed at Facebook and currently used by many organizations, both open- and closed-source, has been trialled by several teams at Mozilla over the last few months. Although no code review tool is perfect, we believe it addresses several of the deficiencies in Review Board and is better suited to the Firefox engineering process. It is also an opportunity to decouple our automation pieces in order to focus on them after Differential’s launch, where we believe we will have a greater impact to Firefox development.<br />
<br />
== What will go out in the initial launch? ==<br />
<br />
# Deployment of a central Differential (code review) installation, supported by CloudOps, along with supporting tools like Diffusion (repository browser) and Herald (event-driven notifications). We will continue to use our Bugzilla instance, bugzilla.mozilla.org (aka BMO), for issue tracking for the foreseeable future.<br />
# Lightweight integration of Differential with BMO. This will include<br />
#* BMO integration, as discussed above.<br />
#* Integration with the Autoland service, which is currently used for around 50% of commits to mozilla-central and an integral part of the Quantum Stylo project.<br />
<br />
== What will happen to Splinter and MozReview? ==<br />
<br />
After a short trial period, MozReview will be shut down, and Splinter will be turned off for the main Firefox products on BMO: Core, Firefox, and Toolkit. Contribution guides and documentation will be updated to refer to Phabricator for code-change submissions. The exact archival procedures are will be figured out soon.<br />
<br />
== Will I be able to request customizations to Differential? ==<br />
<br />
We plan to limit customizations, but not to zero. We’re making this change (to using a third-party tool) to reduce the support burden on internal teams. The fewer customizations we make the more that happens. Any customizations will generally use Phabricator’s Conduit API; extensions will be limited to changes that are not possible to<br />
implement via the API. We have no intention of forking any Phabricator tools.<br />
<br />
== How will I get patches/commits up for review? ==<br />
<br />
To begin with, we will keep to the general Phabricator workflow, including use of the Arcanist command-line tool, although we will likely provide easy installation and some abstraction via mach and MozillaBuild.<br />
<br />
After initial launch, we will build support for "push to review", that is, a commit-based system, similar to MozReview's approach. <br />
<br />
== Where will the flags for feedback/review/ui-review be? ==<br />
<br />
We’re going with the review flow built into Differential, which does not support multiple types of flags as Bugzilla’s attachment-flag system does. However, the actions that a reviewer can perform in Differential are more straightforward: rather than setting “r+” or “r-”, Differential’s options include “resign as reviewer”, “request<br />
changes”, and “accept revision”, which roughly map to clearing a r? flag, setting r-, and setting r+, respectively. Differential also distinguishes between a reviewer and a “blocking reviewer”, which could be seen as requesting feedback versus requesting review. Finally, compared to Bugzilla, Differential has a clearer indication of the current state of the reviews on a revision and what needs to happen.<br />
<br />
We’re using the opportunity presented by switching to a new code review tool to try out this simpler approach, which will particularly benefit new contributors. This is possibly the biggest change in process, and we know it may take some time to get used to.<br />
<br />
== Will I be able to push to review? ==<br />
<br />
Most likely, some time after initial launch.<br />
<br />
A commit-based system offers many advantages over a patch-based system, mostly because of the metadata, including history, preserved in commits. The ability to use hg/git’s “push” command to submit patches for review was also one of the much-appreciated aspects of MozReview. However, it’s a tricky thing to get right. We never solved the problem of confidential patch review in MozReview, since mapping Bugzilla’s security groups to the Mercurial review repository is rather difficult. Our support for micro-/stacked commits was also a bit more confusing than we liked.<br />
<br />
In the interests of doing a staggered launch and iterative development, and so users can start to get used to Differential as soon as possible, the initial launch will only support the standard Phabricator methods for submitting changes, that is, arc (and via the web UI, although that is less convenient and powerful). We will build a commit-based system around Phabricator soon after.<br />
<br />
== Will there be alternative code review tools available? ==<br />
<br />
No single tool is going to make everyone happy, but we don’t plan to support multiple tools.<br />
<br />
== What will the team do if they won’t be working on the tool itself? ==<br />
<br />
In addition to (re)building a commit-based system, we have plenty of things lined up already. Here are a few:<br />
<br />
* Linting upon patch submission.<br />
* Fully automated landings. Signal your intention to land a patch when you submit it, and after it gets reviewed by authorized developers Autoland will land it automatically.<br />
* Automatic conflict detection, indicating if a patch can’t be cleanly applied to the tree before you try to land it, or even before it’s reviewed.<br />
* Automatic, intelligent Try runs based on what parts of the code were modified.<br />
* Tracking a patch through its lifecycle: review, landing, merges, uplifts, and any backouts along the way.<br />
<br />
The pattern here is that these are automated analyses and actions that are part of a pipeline from patch submission to review to landing to<br />
release. These are the steps in the engineering process that are largely unique to Firefox’s complex and highly scaled nature. Our team<br />
believes that the biggest positive impact to developer productivity lies in this area.<br />
<br />
As noted above, these enhancements are either dependent on or greatly simplified by a commit-based model, which will we (re)build first.<br />
<br />
== We are we rebuilding parts of MozReview around Phabricator? ==<br />
<br />
MozReview started out as an experiment and prototype that simultaneously delivered a new code review tool with some process automation. A lot of this automation was built into Review Board extensions and, later, into a custom fork. We also customized the tool to mimic the BMO patch review process as closely as we could.<br />
<br />
Making major changes to Review Board and tightly coupling process automation to it resulted in a heavily constrained development environment and increasing maintenance burdens. Last year we came to the realization that a major architectural change and a refocusing of priorities were overdue.<br />
<br />
At the same time we took a hard look at Review Board and concluded that, even without the added complexities of our customizations, it had some problems and deficiencies that were rather difficult to fix, including loading times, inaccuracies and omissions in diffs, and basic UI structure. Taking a look at alternative code-review solutions, of which none are perfect, it seems that Differential better meets Firefox engineering’s needs and already has some supporters at Mozilla.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow&diff=1204025Engineering Workflow2018-11-16T18:24:36Z<p>Mcote: update to systems and work</p>
<hr />
<div>== Our mission ==<br />
<br />
The Engineering Workflow team exists to improve the quality, clarity, and efficiency of Firefox development through the integration and development of tools and automation.<br />
<br />
== Our team ==<br />
<br />
We are generalists who work on everything from web apps to VCS deployments and integrations to build systems. We are part of the Engineering Operations department.<br />
<br />
== Our systems ==<br />
<br />
The major systems for which Engineering Workflow is responsible includes the following:<br />
<br />
* [[BMO|bugzilla.mozilla.org (BMO)]]<br />
* [[Phabricator]]<br />
* [https://lando.services.mozilla.com Lando]<br />
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build Firefox build]<br />
* [https://hg.mozilla.org hg.mozilla.org]<br />
* [[Auto-tools/Projects/Pulse|Pulse & PulseGuardian]]<br />
<br />
We also drive process changes and related automation such as [https://bugzilla.mozilla.org/show_bug.cgi?id=1454867 third-party manifests].<br />
<br />
See our [[/Road Map|road map]] of future work to these and new systems.</div>Mcotehttps://wiki.mozilla.org/index.php?title=BugzillaAutoLanding&diff=1202881BugzillaAutoLanding2018-10-25T01:00:34Z<p>Mcote: Lando is the new autoland</p>
<hr />
<div>This project has been superseded by [https://lando.services.mozilla.com Lando], which hooks into [https://phabricator.services.mozilla.com Phabricator].</div>Mcotehttps://wiki.mozilla.org/index.php?title=BMO/AutoLand&diff=1202880BMO/AutoLand2018-10-24T23:50:39Z<p>Mcote: Lando is the new autoland</p>
<hr />
<div>The former content on this page refers to an ancient autoland system.<br />
<br />
The modern version of autoland is [https://lando.services.mozilla.com Lando].</div>Mcotehttps://wiki.mozilla.org/index.php?title=Auto-tools/Projects/Autoland&diff=1202879Auto-tools/Projects/Autoland2018-10-24T23:49:59Z<p>Mcote: Lando is the new autoland</p>
<hr />
<div>The current incarnation of automatic code landings at Mozilla is [https://lando.services.mozilla.com Lando].</div>Mcotehttps://wiki.mozilla.org/index.php?title=EngineeringProductivity/Projects/MozReview&diff=1202877EngineeringProductivity/Projects/MozReview2018-10-24T23:46:45Z<p>Mcote: MozReview is no more</p>
<hr />
<div>MozReview has been decommissioned in favour of [https://phabricator.services.mozilla.com Phabricator] and [https://lando.services.mozilla.com Lando].</div>Mcotehttps://wiki.mozilla.org/index.php?title=ReleaseEngineering:Autoland&diff=1202876ReleaseEngineering:Autoland2018-10-24T23:44:59Z<p>Mcote: Lando is the new autoland</p>
<hr />
<div>The former content on this pager refers to an ancient version of the autoland system.<br />
<br />
The current autoland system is [https://lando.services.mozilla.com Lando].</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202398Phabricator/FAQ2018-10-15T21:33:07Z<p>Mcote: Clarify title and use consistent quotes</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
Note that you will need to run "arc diff" again to update the patch even if you don't need to change it (e.g. the bustage was in an earlier commit). This is because Phabricator updates the revision after it lands but does not provide the necessary metadata that Lando needs. See {{bug|1489126}}.<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself. See {{bug|1475915}}.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== Command-line tools: moz-phab and arc ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the "contains arc fields" error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202397Phabricator/FAQ2018-10-15T21:31:33Z<p>Mcote: link to review-request-blocking bug</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
Note that you will need to run "arc diff" again to update the patch even if you don't need to change it (e.g. the bustage was in an earlier commit). This is because Phabricator updates the revision after it lands but does not provide the necessary metadata that Lando needs. See {{bug|1489126}}.<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself. See {{bug|1475915}}.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== 'moz-phab' and 'arc' ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the 'contains arc fields' error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202396Phabricator/FAQ2018-10-15T21:30:37Z<p>Mcote: Add note about needing to rerun "arc diff" after a backout</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
Note that you will need to run "arc diff" again to update the patch even if you don't need to change it (e.g. the bustage was in an earlier commit). This is because Phabricator updates the revision after it lands but does not provide the necessary metadata that Lando needs. See {{bug|1489126}}.<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== 'moz-phab' and 'arc' ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the 'contains arc fields' error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202394Phabricator/FAQ2018-10-15T20:35:27Z<p>Mcote: "Done" is now checked by default when the author leaves a comment, so removing this entry</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== 'moz-phab' and 'arc' ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the 'contains arc fields' error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202327Phabricator/FAQ2018-10-14T20:26:01Z<p>Mcote: replace section with updated approach</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror review flags to Bugzilla? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard and can be misleading. There are no direct equivalents between Differential's review actions and state and Bugzilla's flags. Furthermore, the full state of a review is not exposed by Phabricator's Conduit API. See [https://groups.google.com/d/msg/mozilla.dev.platform/Aku1WPL5190/rBcGX3rkBwAJ this dev.platform post] for more information.<br />
<br />
We will be including some revision metadata in associated bugs at some point; see {{bug|1489706}}.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== 'moz-phab' and 'arc' ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the 'contains arc fields' error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1202031Phabricator/FAQ2018-10-06T01:56:09Z<p>Mcote: /* Lando */ clarify two related FAQ entries</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes. Only people who are CC'd on the Bugzilla bug will be able to see your revision.<br />
<br />
Note there may be a short delay after submission before the revision is visible to other users.<br />
<br />
Reviews are connected with the BMO security groups. All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box at the bottom of the page.<br />
<br />
[[File:Closed revision actions.png|320px|Closed revision actions]]<br />
<br />
See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
'''TIP''': Like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== Why don't we mirror 'r?' and other review states to Bugzilla, why just 'r+'? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard.<br />
<br />
r+ is simple enough and valuable enough to handle, however the other states are more complicated and there isn't a direct mapping force each of the states the two systems use.<br />
<br />
See [https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ this dev-platform post] for more information.<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
=== Can I filter Phabricator mails in gmail? ===<br />
<br />
Yes, if you enable stamps in e-mail bodies. There's some examples in the [https://secure.phabricator.com/book/phabricator/article/mail_rules/#stamps-and-gmail upstream documentation].<br />
<br />
=== Why does logging into Phabricator require 2FA/MFA? ===<br />
<br />
Anyone using Phabricator is authoring patches, reviewing patches, and/or accessing confidential patches. We feel MFA is a reasonable burden for these people given the importance of maintaining secure processes in the development of Firefox and other Mozilla apps. Given that Bugzilla is coupled to Phabricator, and a lot of important discussion around bugs and solutions also happens in Bugzilla, including confidential discussions, anyone involved in the above activities on Phabricator should also have equal protections when accessing Bugzilla.<br />
<br />
== 'moz-phab' and 'arc' ==<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== How do I fetch and apply changes to a local repository? ===<br />
<br />
Provided all dependent revisions have been submitted to Phabricator and not<br />
replaced with updated diffs, the "Related Revisions" have been set up<br />
correctly, and the first revision in the related revision chain has a parent<br />
commit hash corresponding to a base revision existing in the local mercurial<br />
repository, "arc patch --revision D<NNNNN>" should apply the series to the<br />
appropriate base revision.<br />
<br />
The process is more complicated for retrieving any diffs from revisions that<br />
now have more recent diffs in the related revision chain:<br />
<br />
# The "History" tab for a revision has a list of diff IDs. Identify the diff ID for the diff that is wanted. The creation date may be useful.<br />
# Look through the history of the revision to find changes to the parent revision and guess which was the parent revision at the time the diff was generated from a commit. Changes to parent revisions are manual and so may happen before or after the commit was pushed (if they were accurate at any stage).<br />
# Repeat the process to find a diff ID in the parent revision, and continue until there are no parent revisions. When viewing a particular diff ID, the "Commits" tab will have a commit hash and parent commit hash, if the diff was submitted from moz-phab at least. These may be useful in identifying parent revisions and diffs.<br />
# "arc patch --diff <NNNNN>" may be used to create a commit for the first diff in the series.<br />
# For each subsequent diff use "arc patch --skip-dependencies --diff <NNNNN>". "--skip-dependencies" prevents more recent diffs for parent revisions or diffs for wrong parent revisions being fetched and prevents attempts to apply the specified diff on these incorrect diffs ([https://bugzilla.mozilla.org/show_bug.cgi?id=1485849 Tracked in bug 1485849])<br />
<br />
=== How do I get "arc patch" to apply changes to local tip instead of branching an earlier commit? ===<br />
<br />
Use "arc patch --nobranch [rest of command]". The changes will be applied to the appropriate earlier commit, if known, and rebased.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== arc dies when I do [X]! How do I get debug information out of arc? ===<br />
<br />
Run "arc --trace [rest of command]". You will get a lot of diagnostic information.<br />
<br />
If you've found a bug you can file it under the [https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=Phabricator Phabricator component] in BMO.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== What does the 'contains arc fields' error mean? ===<br />
<br />
The "contains arc fields" error means that revision was previously pushed to Phabricator with arc directly.<br />
<br />
moz-phab doesn't support all the fields that arc itself does, including the "test plan" field. If moz-phab were to rewrite the commit description that information would be lost. Currently moz-phab takes a conservative approach and will stop with the "contains arc fields" error message.<br />
<br />
You can work around that by rewriting the commit description yourself to only include the description and the 'Differential Revision:' line.<br />
<br />
There are plans to both support the "test plan" field and parse an arc formatted commit description with moz-phab.<br />
<br />
== Lando ==<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
If you don't have Level 3, follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.<br />
<br />
If you have Level 3 and are still getting this error, try:<br />
* logging out of auth0 and logging in again<br />
* ssh to hg.mozilla.org and verify that scm_level_3 is reported there<br />
* log into https://prod.testrp.security.allizom.org/ and check that active_scm_level_3 is listed under HTTP_OIDC_CLAIM_USER_PROFILE_HTTPS://SSO_MOZILLA_COM/CLAIM/GROUPS<br />
<br />
If you used to be a volunteer and are now an employee, you likely have two LDAP accounts, and you may not have your commit access associated with the account you used to log into Lando. See the next FAQ entry.<br />
<br />
Otherwise, contact Service Desk, as it indicates a misconfiguration with your account.<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/TestPlan&diff=1201186Phabricator/TestPlan2018-09-18T17:04:55Z<p>Mcote: Remove test cases involving r+s in BMO</p>
<hr />
<div><br />
== Getting Started ==<br />
<br />
The following steps are required to get QA up and running for Phabricator testing on Mozilla's staging server.<br />
<br />
'''NOTE:''' We are using the dev server for QA test runs.<br />
<br />
1. Clone the following repositories to the same directory on your machine:<br />
git clone https://github.com/phacility/libphutil<br />
git clone https://github.com/phacility/arcanist<br />
git clone https://github.com/mozilla-conduit/arcanist --branch master --single-branch cinnabarc<br />
<br />
2. Add vanilla arcanist (<code>bin/arc</code> from your phacility repo checkout) to your path. On OS X and Linux (and the Windows 10 Linux Subsystem), you can add the following to your `~/.bash_profile` (modifying the path appropriately):<br />
alias arc='/Users/youruser/path/to/arcanist/bin/arc'<br />
<br />
Doing so will allow you to use the <code>arc</code> command from anywhere on your machine.<br />
<br />
3. Install git-cinnabar:<br />
<br />
git clone https://github.com/glandium/git-cinnabar.git --branch master --single-branch<br />
export PATH=/Users/youruser/path/to/git-cinnabar:$PATH<br />
cd git-cinnabar && git cinnabar download<br />
<br />
4. Alias Arcanist modified for git-cinnabar use to <code>cinnabarc</code>. This will allow to use both vanilla and modified Arcanist interchangeably:<br />
<br />
alias cinnabarc='/Users/youruser/path/to/cinnabarc/bin/arc'<br />
<br />
5. Clone the repo(s) you plan to test on:<br />
<br />
* <code>hg clone https://hg.mozilla.org/automation/phabricator-qa-dev/</code><br />
* <code>git clone hg::https://hg.mozilla.org/automation/phabricator-qa-dev/ phabricator-qa-dev-cinnabar</code><br />
<br />
6. In the local <code>phabricator-qa-dev</code> repository checkout, run: <br />
<br />
arc install-certificate <br />
<br />
Follow the instructions presented in the command line to associate your local machine with the Phabricator instance via an API key.<br />
<br />
Repeat the process in <code>phabricator-qa-dev-cinnabar</code>. Use <code>cinnabarc</code> instead:<br />
<br />
cinnabarc install-certificate<br />
<br />
7. Test away! You can create branches within your local <code>phabricator-qa-dev</code> repository checkout, add commits, and send them to Phabricator via <code>arc diff .^</code>. See the [http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Mozilla Phabricator User Documentation] for more. <br />
<br />
This should be all you need to get going with arc and our staging and dev servers!<br />
<br />
== Test Plan ==<br />
<br />
These tests will help ensure that our extensions continue to work as expected when Phabricator is upgraded. They are important as Phacility make no guarantees that internal modules/objects/APIs won't change. See the [[Phabricator/UpgradeProcess|upgrade process]] for more.<br />
<br />
Please update this doc with new tests as features are added/changed and as holes in the plan are discovered.<br />
<br />
=== T1 - Signing up is successful ===<br />
<br />
====Test Plan====<br />
# Create a new BMO account.<br />
# Make sure to include an irc nick in the Real Name field.<br />
#* E.g. "John Doe [:jdoe]"<br />
# Go to Phabricator and login as the new user.<br />
# Finish account creation.<br />
<br />
====Results====<br />
# After logging into Phabricator, on the "Create a New Account" page,<br />
## Username should be prefilled with the irc nick,<br />
## Real Name is correct and does not contain [] or any other extraneous characters.<br />
# Clicking register approval completes account creation without error.<br />
# The account works as expected.<br />
<br />
=== T2 - Creating a revision is successful ===<br />
<br />
====Test Plan====<br />
# Make sure you have arc properly setup on your machine and have run <code>arc install-certificate</code> using the Phabricator user you wish to test with as documented above.<br />
# Go to BMO and create a new bug as the Bugzilla user that the Phabricator account is connected to. (Or use an existing public bug).<br />
#* To create bugs directly and bypass triaging, go to https://bugzilla.allizom.org/enter_bug.cgi?product=Firefox&format=__default__ (staging) or https://bugzilla-dev.allizom.org/enter_bug.cgi?product=Firefox&format=__default__ (dev)<br />
# Using the repo listed in the "Getting Started" section above that matches the environment you are testing, make some change to a file.<br />
# Run <code>hg commit -A -m 'commit1: New changes</code><br />
# Run <code>arc diff .^</code><br />
# Input something for the title, summary, test plan, and the correct bug id.<br />
# Save and exit the file.<br />
<br />
====Results====<br />
# <code>arc diff</code> only submitted the 1 newly created commit.<br />
# Visit Phabricator and there should be a new revision with the title.<br />
# The revision should contain the correct diff of the changes that were made.<br />
# The "Bugzilla Bug ID" is correct.<br />
## The Bug number is correct.<br />
## The link is correct based on the environment (bugzilla.allizom.org for staging, bugzilla-dev.allizom.org for dev).<br />
## If the bug in Bugzilla is a public bug, the revision should also be public.<br />
# Visiting the bug on Bugzilla shows an <code>x-phabricator-request</code> attachment.<br />
# Author received an email from <code>mozphab-dev@mozilla.com</code>. It has a title formatted as "[Differential] [Changed Policy] D{revision number}: {first line}." and a body with a text "phab-bot changed the visibility from "Administrators" to "Public (No Login Required)"."<br />
<br />
=== T3 - Updating a revision with an amended commit is successful ===<br />
<br />
====Test Plan====<br />
'''Note''': This would fail, please in the last step use <code>arc diff .^ --update D{number of the revision created above}</code> and omit the first expected result.<br />
<br />
# <code>hg update</code> to a commit which you previously submitted with arc<br />
# Make a change and run <code>hg commit --amend</code><br />
# Run <code>arc diff .^</code><br />
<br />
====Results====<br />
# arc should automatically detect a revision and ask you if you want to update it.<br />
# The revision is updated with the new diff on Phabricator:<br />
## The History tab should have two entries, Diff 1 and Diff 2.<br />
## The Commits tab should have a single entry.<br />
# The bug id and other information remains unchanged.<br />
<br />
=== T4 - Creating a secure revision is successful ===<br />
<br />
Your Bugzilla user must belong to a security group, e.g. core-security.<br />
<br />
====Test Plan====<br />
# Go to bugzilla and create a security bug:<br />
#* Click "Edit Bug", open the "Security" panel, and check one of the security-sensitive boxes, e.g. "Security-Sensitive Core Bug".<br />
# Create a new hg commit.<br />
# Run <code>arc diff .^</code>.<br />
# Enter the title, summary, test plan, and the bug id of the security bug.<br />
# Submit the revision.<br />
<br />
====Results====<br />
# The diff and information of the revision are as expected.<br />
# The revision has a "Custom Policy" attached to it.<br />
# Click "Edit Revision" and then click on the "Visible To" drop down, and select the "Custom Policy" choice.<br />
#* It should read "Allow members of projects", followed by the names of projects corresponding to all Bugzilla groups the private bug is categorized under. For example, a bug private to core-security, should have the project name "bmo-core-security".<br />
# The revision has a "secure-revision" project tag added.<br />
# The revision has a warning titled "This is a secure revision.".<br />
# The revision added the creator as a subscriber.<br />
# The revision is visible to the user who made it.<br />
# The revision is visible to users belonging to the security groups of the bug.<br />
# There is an <code>x-phabricator-request</code> attachment on the bug in Bugzilla.<br />
# The revision is NOT visible to the public without logging in.<br />
# The revision is NOT visible to logged in members without the correct permission.<br />
<br />
=== T5 - Adding a secure bug to an existing revision locks it down ===<br />
<br />
Your Bugzilla user must belong to a security group, e.g. core-security. You will also need a second, unprivileged user.<br />
<br />
====Test Plan====<br />
# Create a new hg commit.<br />
# Run <code>arc diff .^</code>.<br />
# Enter the title, summary, and test plan. Do not include a bug number.<br />
# Submit the revision. <br />
# Check if revision is available for public.<br />
# Go to bugzilla and create a security bug:<br />
#* Click "Edit Bug", open the "Security" panel, and check one of the security-sensitive boxes, e.g. "Security-Sensitive Core Bug".<br />
# Edit the revision created above, and set the Bugzilla Bug ID field to the ID of the newly created bug.<br />
# Add the second, unprivileged Bugzilla user to the bug's CC list.<br />
<br />
====Results====<br />
# The revision has a "Custom Policy" attached to it.<br />
# Click "Edit Revision" and then click on the "Visible To" drop down, and select the "Custom Policy" choice.<br />
#* It should read "Allow members of projects", followed by the names of projects corresponding to all Bugzilla groups the private bug is categorized under. For example, a bug private to core-security, should have the project name "bmo-core-security".<br />
# The revision has a "secure-revision" project tag added.<br />
# The revision has the creator and the second Bugzilla user as subscribers.<br />
# The revision is visible to the user who made it.<br />
# The revision is visible to users belonging to the security groups of the bug.<br />
# The revision is NOT visible to the public without logging in.<br />
# The revision is NOT visible to logged in members without the correct permission.<br />
# The revision IS visible to the second Bugzilla user.<br />
# There is an <code>x-phabricator-request</code> attachment on the bug in Bugzilla.<br />
# The reviewer received an email from the author with a text "The content for this message can only be transmitted over a secure channel." and a link to Phabricator.<br />
<br />
=== T6 - Creating a revision checks the bug id ===<br />
<br />
====Test Plan====<br />
# Create a new hg commit.<br />
# Run <code>arc diff .^</code><br />
# Enter information for the title, summary, and test plan.<br />
# Enter the bug id as specified for each expected result below.<br />
<br />
====Results====<br />
# Entering an invalid bug id, e.g "abcd efg" or "$1000", fails.<br />
# Entering the id of a bug that does not exist fails.<br />
# Entering the id of a bug of a secure revision that the user does not have access to fails.<br />
# Entering a valid bug id is successful.<br />
<br />
=== T7 - Creating multiple revisions with the same bug id is successful ===<br />
<br />
====Test Plan====<br />
# Create a new hg commit.<br />
# Run <code>arc diff .^</code><br />
# Enter information for the title, summary, and test plan.<br />
# Enter the bug id.<br />
# Repeat and create another revision with the same bug id.<br />
<br />
====Result====<br />
# Both revisions are created successfully.<br />
# There are 2 corresponding <code>x-phabricator-request</code> attachments on the bug in Bugzilla.<br />
<br />
=== T8 - Requesting and leaving a review on a revision is successful ===<br />
<br />
====Test Plan====<br />
# Ensure that you have 2 Phabricator accounts that log in via Bugzilla ready to go.<br />
# Create a commit, run <code>arc diff .^</code>.<br />
# Input the title, summary, test plan, and bug id of a public bug.<br />
# For the "Reviewers" field enter the Phabricator username of the other account.<br />
# Log into Phabricator as the reviewer account.<br />
# Add the "Accept Revision" action at the bottom. Submit.<br />
# Add the "Request Changes" action at the bottom. Submit.<br />
<br />
====Results====<br />
# The Phabricator attachment on Bugzilla is present.<br />
# Reviewer received an email from author with a text "{author} added a reviewer: {reviewer}"<br />
# Author received an email from reviewer with a text "{reviewer} accepted this revision."<br />
# Author received an email from reviewer with a text "{reviewer} requested changes to this revision."<br />
<br />
=== T9 - Abandoning a revision obsoletes the attachment ===<br />
<br />
====Test Plan====<br />
# Create a new bug.<br />
# Create a commit and run <code>arc diff .^</code>.<br />
# Input the title, summary, test plan, and bug id of the newly created bug.<br />
# Go to the newly created revision and perform the "Abandon Revision" action from the "Add Action" dropdown.<br />
<br />
====Results====<br />
# The bug has no active attachments listed.<br />
# The bug has one obsolete attachment listed, linking to the created revision.<br />
<br />
=== T10 - Reclaiming a revision unobsoletes the attachment ===<br />
<br />
====Test Plan====<br />
# In the revision created as part of the "Abandoning a revision obsoletes the attachment" test, perform the "Reclaim revision" action.<br />
<br />
====Results====<br />
# The bug's Phabricator attachment is unobsoleted.<br />
<br />
=== T11 - Creating a Diff from local git repository to remote Mercurial repository is not allowed ===<br />
<br />
====Test Plan====<br />
# Change directory to the repository <code>phabricator-qa-dev-cinnabar</code>.<br />
# Create a commit with git and run <code>arc diff HEAD~</code>.<br />
# Fill the needed data (<code>Test Plan</code>) and confirm.<br />
<br />
====Results====<br />
# Creating a diff fails with :<br />
<br />
ERR-CONDUIT-CORE: Local VCS (git) is different from the remote repository VCS (hg).<br />
<br />
=== T12 - Patching Diff created from git repository ===<br />
<br />
====Test Plan====<br />
# Using a commit created above run <code>cinnabarc diff HEAD~</code>.<br />
# Fill the needed data (<code>Test Plan</code>) and confirm.<br />
# Change directory to <code>phabricator-qa-dev</code>.<br />
# Run <code>arc patch D{number of the revision created above}</code>.<br />
<br />
====Results====<br />
# Code is sucessfully patched using the Diff.<br />
<br />
=== T13 - Verify the private revisions deliver emails that does not contain any sensitive content ===<br />
<br />
Your Bugzilla user must belong to a security group, e.g. core-security.<br />
<br />
====Test Plan====<br />
# Login to Phabricator (after creating account in Bugzilla) using an account that can have email delivered to it, such as your own email address.<br />
# At the top right of Phabricator, click on your initial or gravatar image to open the drop down menu and select "Settings".<br />
# Click on "Email Delivery".<br />
# Select "Enable Self Action Mail" for the "Self Action" drop down.<br />
# Click "Save Changes".<br />
# Go to Bugzilla and create a security bug:<br />
#* Click "Edit Bug", open the "Security" panel, and check one of the security-sensitive boxes, e.g. "Security-Sensitive Core Bug".<br />
# Create a new hg commit.<br />
# Run <code>arc diff .^</code>.<br />
# Enter the title, summary, test plan, and the bug id of the security bug.<br />
# Submit the revision.<br />
<br />
====Results====<br />
# The diff and information of the revision are as expected.<br />
# The revision has a "Custom Policy" attached to it.<br />
# The revision has a "secure-revision" project tag added.<br />
# The revision has a warning titled "This is a secure revision".<br />
# Check to see if you received an email about the new object (Revision) that was just created.<br />
# The email should not contain any information about the revision other than a link to Phabricator.<br />
# Clicking on the link in the email should take you to the Phabricator page that displays the full unfiltered email contents.<br />
# The email contents should contain the title, summary, test plan, reviewers, etc. of the new revision.<br />
# Submitting a public revision should instead show the full contents in the email similar to what was displayed on the Phabricator mail page.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1199640Phabricator/FAQ2018-08-17T19:09:43Z<p>Mcote: /* How do I reopen an existing revision to upload more patches for review (e.g. following a backout)? */ change question slightly</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to submit more updates for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box. See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
Additionally, like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== Why don't we mirror 'r?' and other review states to Bugzilla, why just 'r+'? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard.<br />
<br />
r+ is simple enough and valuable enough to handle, however the other states are more complicated and there isn't a direct mapping force each of the states the two systems use.<br />
<br />
See [https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ this dev-platform post] for more information.<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes, unlike MozReview, commits for security bugs can be submitted to Phabricator as access to the reviews are connected with the BMO security groups.<br />
<br />
All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
Note this means there may be a short delay after submission before the revision is visible to other users.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
== Lando ==<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
Follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1199639Phabricator/FAQ2018-08-17T19:09:00Z<p>Mcote: Include link to "Other Revision Actions" in our phab docs</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to upload more patches for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box. See also https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#other-revision-actions for descriptions of other non-review-related actions you might want to take on a revision.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
Additionally, like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== Why don't we mirror 'r?' and other review states to Bugzilla, why just 'r+'? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard.<br />
<br />
r+ is simple enough and valuable enough to handle, however the other states are more complicated and there isn't a direct mapping force each of the states the two systems use.<br />
<br />
See [https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ this dev-platform post] for more information.<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes, unlike MozReview, commits for security bugs can be submitted to Phabricator as access to the reviews are connected with the BMO security groups.<br />
<br />
All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
Note this means there may be a short delay after submission before the revision is visible to other users.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
== Lando ==<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
Follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1199636Phabricator/FAQ2018-08-17T16:49:29Z<p>Mcote: Blocking review requests in Phabricator</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to upload more patches for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
Additionally, like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== Why don't we mirror 'r?' and other review states to Bugzilla, why just 'r+'? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard.<br />
<br />
r+ is simple enough and valuable enough to handle, however the other states are more complicated and there isn't a direct mapping force each of the states the two systems use.<br />
<br />
See [https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ this dev-platform post] for more information.<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes, unlike MozReview, commits for security bugs can be submitted to Phabricator as access to the reviews are connected with the BMO security groups.<br />
<br />
All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
Note this means there may be a short delay after submission before the revision is visible to other users.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
=== Can I block review requests in Phabricator like I can in BMO? ===<br />
<br />
Unfortunately, BMO's system to block review requests isn't suitable for Phabricator because communication with BMO after a revision is created is asynchronous to make the system faster and more robust. We are, however, currently looking into ways we can implement this functionality within Phabricator itself.<br />
<br />
== Lando ==<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
Follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1199634Phabricator/FAQ2018-08-17T16:46:07Z<p>Mcote: Arcanist on Windows</p>
<hr />
<div>= Phabricator and Lando FAQs =<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
== Phabricator ==<br />
<br />
=== When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’ ===<br />
<br />
This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
=== How do I reply to an inline comment without leaving another comment that I have to mark as "Done"? ===<br />
<br />
The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
=== How do I '''require''' a review from all reviewers before landing? ===<br />
<br />
Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
=== Can I remove "Tags: #secure-revision" from my changeset’s commit message? ===<br />
<br />
"#secure-revision" is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
=== Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?) ===<br />
<br />
No. Each commit is associated with a single revision.<br />
<br />
=== How do I get “arc diff” to stop listing and asking about all my untracked build artifacts? ===<br />
<br />
Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Why do I get the following error during patch submission: "Error parsing field "Reviewers": The objects you have listed include objects which do not exist (name)."? ===<br />
<br />
The specified name either does not have a Phabricator account, or is using a different nick on Phabricator than the one you specified.<br />
<br />
=== How do I reopen an existing revision to upload more patches for review (e.g. following a backout)? ===<br />
<br />
Use the action drop down, just above the comment box.<br />
<br />
=== How do I download the patch or a file from Phabricator and apply it locally? ===<br />
<br />
* Use the '''arc patch''' command to download and apply a diff:<br />
[[File:Arc patch.png|320px|Arc Patch]]<br />
<br />
* Manually download just the diff from the menu on the right side of the page:<br />
[[File:Download_Raw_Diff.png|320px|Download Raw Diff]]<br />
<br />
To download an individual file from within the page, use the "Show Raw File" options under "View Options":<br />
<br />
[[File:Show_Raw_File.png|320px|View Options Menu]]<br />
<br />
=== How do I hide inline comments? ===<br />
<br />
Controls for this will appear when scrolling over a diff. You'll get a bar that sticks to the top of the viewport and lets you hide/show in a number of ways.<br />
<br />
[[File:Fully-hide-comments.png|320px|Full Hide Comments Menu]]<br />
<br />
Additionally, like most actions there's a keyboard shortcut for this - "Shift + A". Pro tip: pressing "?" will show all the keyboard shortcuts.<br />
<br />
=== "arc diff" fails on Windows: Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 ===<br />
<br />
arc diff --trace<br />
...<br />
EXCEPTION: (Exception) Failed to passthru proc_open(): proc_open(): CreateProcess failed, error code - 2 at [<phutil>\src\future\exec\PhutilExecPassthru.php:103]<br />
arcanist(head=master, ref.master=875d01836037), phutil(head=master, ref.master=1613e68f4740)<br />
#0 PhutilExecPassthru::execute() called at [<phutil>\src\future\exec\execx.php:50]<br />
#1 phutil_passthru(string, PhutilCommandString) called at [<phutil>\src\console\PhutilInteractiveEditor.php:122]<br />
#2 PhutilInteractiveEditor::invokeEditor(string, string, integer) called at [<phutil>\src\console\PhutilInteractiveEditor.php:77]<br />
#3 PhutilInteractiveEditor::editInteractively() called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:1889]<br />
#4 ArcanistDiffWorkflow::getUpdateMessage(array, string) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:773]<br />
#5 ArcanistDiffWorkflow::buildRevisionFromCommitMessage(ArcanistDifferentialCommitMessage) called at [<arcanist>\src\workflow\ArcanistDiffWorkflow.php:478]<br />
#6 ArcanistDiffWorkflow::run() called at [<arcanist>\scripts\arcanist.php:394] <br />
<br />
arc needs to be configured with the full path to your editor (it doesn't check your PATH).<br />
<br />
See [https://secure.phabricator.com/book/phabricator/article/arcanist_windows/ Arcanist User Guide: Windows] for instructions on how to set this correctly.<br />
<br />
=== Why don't we mirror 'r?' and other review states to Bugzilla, why just 'r+'? ===<br />
<br />
Keeping flags mirrored between two distributed systems that have different data models is hard.<br />
<br />
r+ is simple enough and valuable enough to handle, however the other states are more complicated and there isn't a direct mapping force each of the states the two systems use.<br />
<br />
See [https://groups.google.com/forum/#!msg/mozilla.dev.platform/Y8kInYxo8UU/tsF7UfxvBgAJ this dev-platform post] for more information.<br />
<br />
=== Can I use Phabricator for patches to security bugs? ===<br />
<br />
Yes, unlike MozReview, commits for security bugs can be submitted to Phabricator as access to the reviews are connected with the BMO security groups.<br />
<br />
All revisions on Phabricator are initially non-public; when Bugzilla sees a new revision it checks the visibility of the bug and will update the revision to match: revisions referencing public bugs will be made public, and non-public bugs result in the BMO security group and CC list being mapped to the revision's policies. These are kept in sync as the bug changes.<br />
<br />
Note this means there may be a short delay after submission before the revision is visible to other users.<br />
<br />
=== The official docs on installing Arcanist on Windows are ... not great. Are there better ones somewhere? ===<br />
<br />
Yes! We recently published our own step-by-step guide that should be clearer than the official ones: https://moz-conduit.readthedocs.io/en/latest/arcanist-windows.html<br />
<br />
== Lando ==<br />
<br />
=== My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes? ===<br />
<br />
You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.<br />
<br />
To request a password [https://bugzilla.mozilla.org/enter_bug.cgi?product=Infrastructure%20%26%20Operations&component=MOC%3A%20Service%20Requests file a bug requesting a password reset] '''while logged in to your account with SCM permissions'''.<br />
<br />
Note the SSO login system only allows you to be logged into one account at a time; when you log in with your community account any existing Mozilla Corporation sessions will be invalidated. You can work around this by pinning Lando to a different Firefox container, use a private browsing window, using a different Firefox profile, or using a different browser.<br />
<br />
=== Lando says "This diff does not have the proper author information uploaded to Phabricator", but I used "arc diff" to upload my patch. What's wrong? ===<br />
<br />
This can happen if you have not set an author email in your '''.hgrc''' file. Set your author email in your '''.hgrc''' to your username, '''Firstname Lastname <yourldapemail@mozilla.com>'''. Update your commit so it contains the new author data. Re-run '''arc diff''' so that the new commit+data is uploaded to Phabricator.<br />
<br />
=== Lando says "You have insufficient permissions to land. Level 3 Commit Access is required." What do I do? ===<br />
<br />
Follow the guidelines for the repository you're trying to land code in. For mozilla-central, add the "checkin-needed" keyword to the associated bug.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1197159Engineering Workflow/Road Map2018-07-12T01:47:17Z<p>Mcote: Commit series work</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Better support for commit series in Phabricator and Lando ===<br />
<br />
The official command-line interface for Phabricator, Arcanist, does not meet the needs of engineering when it comes to first-class support for submitting, updating, and pulling down series of commits. Lando also does not currently support the atomic landing of an entire series of commits. We will build a new command-line interface to Phabricator and extend Lando to better support standard Firefox engineering practices.<br />
<br />
Impact:<br />
* Efficiently submit and update commit series, encouraging smaller commits.<br />
* Smoothly land commit series, avoiding repetitive clicking and the possibility of merge conflicts.<br />
* Eventually, ease the contribution pipeline by not requiring the installation of Arcanist, which can be annoying on some platforms (primarily Windows).<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Vanilla (cinnabar-less) Git support for mozilla-central ===<br />
<br />
git-cinnabar was created to allow developers to use Git to interact with Mercurial, mainly [https://hg.mozilla.org|hg.mozilla.org]. It has some downsides, however, such as being a bit tricky to install. Ideally developers would be able to use vanilla Git to contribute to Firefox.<br />
<br />
If we view Phabricator and Lando as a conduit to getting code into mozilla-central, then ultimately VCS clients would only need to talk to Phabricator. Phabricator natively supports both Mercurial and Git<sup>[[#vcs-parent-note|1]]</sup>, and full Lando support means that developers will not need to talk to hg.mozilla.org directly. We just need to ensure that the user experience of submitting a patch in progress to Try remains as straightforward as it is today.<br />
<br />
Impact:<br />
* No need to maintain nor educate people on git-cinnabar.<br />
* End to unproductive VCS debates.<br />
* Solidifies Phabricator-Lando as the conduit to hg.mozilla.org; this consolidation will make it easier to add more services and automation to the commit pipeline.<br />
<br />
<div id="vcs-parent-note><small><br />
1. There is one wrinkle in supporting two VCSes for the same repository: like figuring out parent commits when a different VCS is used to pull down commits; see {{bug|1443375}} for how this was solved with git-cinnabar.</small></div><br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===<br />
<br />
== Done ==<br />
<br />
=== Phabricator integration ===<br />
<br />
The bulk of Phabricator integration into BMO was completed in May. Phabricator is now available for general usage.<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1197158Engineering Workflow/Road Map2018-07-12T01:41:10Z<p>Mcote: move a couple items to Done</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Vanilla (cinnabar-less) Git support for mozilla-central ===<br />
<br />
git-cinnabar was created to allow developers to use Git to interact with Mercurial, mainly [https://hg.mozilla.org|hg.mozilla.org]. It has some downsides, however, such as being a bit tricky to install. Ideally developers would be able to use vanilla Git to contribute to Firefox.<br />
<br />
If we view Phabricator and Lando as a conduit to getting code into mozilla-central, then ultimately VCS clients would only need to talk to Phabricator. Phabricator natively supports both Mercurial and Git<sup>[[#vcs-parent-note|1]]</sup>, and full Lando support means that developers will not need to talk to hg.mozilla.org directly. We just need to ensure that the user experience of submitting a patch in progress to Try remains as straightforward as it is today.<br />
<br />
Impact:<br />
* No need to maintain nor educate people on git-cinnabar.<br />
* End to unproductive VCS debates.<br />
* Solidifies Phabricator-Lando as the conduit to hg.mozilla.org; this consolidation will make it easier to add more services and automation to the commit pipeline.<br />
<br />
<div id="vcs-parent-note><small><br />
1. There is one wrinkle in supporting two VCSes for the same repository: like figuring out parent commits when a different VCS is used to pull down commits; see {{bug|1443375}} for how this was solved with git-cinnabar.</small></div><br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===<br />
<br />
== Done ==<br />
<br />
=== Phabricator integration ===<br />
<br />
The bulk of Phabricator integration into BMO was completed in May. Phabricator is now available for general usage.<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1197152Phabricator/FAQ2018-07-11T18:26:09Z<p>Mcote: /* Phabricator */ scale image down</p>
<hr />
<div>== Phabricator and Lando FAQ ==<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
=== Phabricator ===<br />
'''Question:''' When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’?<br />
<br />
'''Answer:''' This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I reply to an inline comment without leaving another comment that I have to mark as "Done"?<br />
<br />
'''Answer:''' The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I '''require''' a review from all reviewers before landing?<br />
<br />
'''Answer:''' Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|640px|Selecting blocking vs nonblocking reviewers]]<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I remove "Tags: #secure-revision" from my changeset’s commit message?<br />
<br />
'''Answer:''' #secure-revision is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?)<br />
<br />
'''Answer:''' No. Each commit is associated with a single revision.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I get “arc diff” to stop listing and asking about all my untracked build artifacts?<br />
<br />
'''Answer:''' Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Lando ===<br />
<br />
'''Question:''' My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes?<br />
<br />
'''Answer:''' You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.</div>Mcotehttps://wiki.mozilla.org/index.php?title=File:Blocking_reviewers.png&diff=1197151File:Blocking reviewers.png2018-07-11T18:21:33Z<p>Mcote: Phabricator screenshot showing the UI for choosing blocking versus nonblocking reviewers.</p>
<hr />
<div>Phabricator screenshot showing the UI for choosing blocking versus nonblocking reviewers.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1197150Phabricator/FAQ2018-07-11T18:15:09Z<p>Mcote: link to image</p>
<hr />
<div>== Phabricator and Lando FAQ ==<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
=== Phabricator ===<br />
'''Question:''' When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’?<br />
<br />
'''Answer:''' This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I reply to an inline comment without leaving another comment that I have to mark as "Done"?<br />
<br />
'''Answer:''' The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I '''require''' a review from all reviewers before landing?<br />
<br />
'''Answer:''' Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
[[File:blocking_reviewers.png|Selecting blocking vs nonblocking reviewers]]<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I remove "Tags: #secure-revision" from my changeset’s commit message?<br />
<br />
'''Answer:''' #secure-revision is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?)<br />
<br />
'''Answer:''' No. Each commit is associated with a single revision.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I get “arc diff” to stop listing and asking about all my untracked build artifacts?<br />
<br />
'''Answer:''' Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Lando ===<br />
<br />
'''Question:''' My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes?<br />
<br />
'''Answer:''' You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1197149Phabricator/FAQ2018-07-11T18:11:39Z<p>Mcote: add <hr>s to separate out the questions</p>
<hr />
<div>== Phabricator and Lando FAQ ==<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
=== Phabricator ===<br />
'''Question:''' When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’?<br />
<br />
'''Answer:''' This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I reply to an inline comment without leaving another comment that I have to mark as "Done"?<br />
<br />
'''Answer:''' The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I '''require''' a review from all reviewers before landing?<br />
<br />
'''Answer:''' Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I remove "Tags: #secure-revision" from my changeset’s commit message?<br />
<br />
'''Answer:''' #secure-revision is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
<hr> <br />
<br />
'''Question:''' Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?)<br />
<br />
'''Answer:''' No. Each commit is associated with a single revision.<br />
<br />
<hr> <br />
<br />
'''Question:''' How do I get “arc diff” to stop listing and asking about all my untracked build artifacts?<br />
<br />
'''Answer:''' Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Lando ===<br />
<br />
'''Question:''' My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes?<br />
<br />
'''Answer:''' You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator/FAQ&diff=1197148Phabricator/FAQ2018-07-11T18:09:53Z<p>Mcote: Created page with "== Phabricator and Lando FAQ == This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear oth..."</p>
<hr />
<div>== Phabricator and Lando FAQ ==<br />
<br />
This FAQ is a collection of questions from users that have come up in IRC, Slack, and elsewhere. Please feel free to add more if you hear other questions coming up frequently. Note that you can always ask questions of both the development team and other users in #phabricator and #lando on IRC and Slack.<br />
<br />
=== Phabricator ===<br />
'''Question:''' When I clicking the Phabricator “Log In or Register” button, why is a new tab is opened with the exception ‘Unhandled Exception(“AphrontMalformedRequestException”) Your browser did not submit a “phcid” cookie with client state information in the request’?<br />
<br />
'''Answer:''' This can happen to users who are using containers for Bugzilla. Instead of clicking on the “Log In or Register” button, copy Phabricator the login page URL into the same container as Bugzilla. You may want to consider adding Phabricator and/or Lando to the same container as Bugzilla.<br />
<br />
'''Question:''' How do I reply to an inline comment without leaving another comment that I have to mark as "Done"?<br />
<br />
'''Answer:''' The "Done" checkbox always accompanies comments/replies. This is built into Phabricator.<br />
<br />
'''Question:''' How do I '''require''' a review from all reviewers before landing?<br />
<br />
'''Answer:''' Add all reviewers as "blocking" reviewers, either from the UI or by appending a “!” to their name when specifying them in Arcanist. To set a reviewer as blocking in the UI, edit the revision and use the reviewer autocomplete; each result will have a normal and a "blocking" entry.<br />
<br />
'''Question:''' Can I remove "Tags: #secure-revision" from my changeset’s commit message?<br />
<br />
'''Answer:''' #secure-revision is a project tag attached to the revision at the time the commit message is auto-generated. The tag is removed slightly later once Bugzilla has had a chance to update the revisions security policies. After Bugzilla has done this update, you can use "arc amend" to update the commit message with the current state. We are currently working on a custom client that may omit the project tags from the commit message altogether.<br />
<br />
'''Question:''' Can I close multiple revisions with one commit message? (by including multiple “Differential Revision:” lines?)<br />
<br />
'''Answer:''' No. Each commit is associated with a single revision.<br />
<br />
'''Question:''' How do I get “arc diff” to stop listing and asking about all my untracked build artifacts?<br />
<br />
'''Answer:''' Use the “--allow-untracked” option to arc diff.<br />
<br />
=== Lando ===<br />
<br />
'''Question:''' My SCM level is bound to a different LDAP account from my Mozilla one. How do I log into Lando to land changes?<br />
<br />
'''Answer:''' You will need to log into the account that is associated with your SCM permissions. If you have only ever accessed that account by ssh key, that is, to push up commits, you will likely need to request a password change to be able to use Auth0.</div>Mcotehttps://wiki.mozilla.org/index.php?title=Phabricator&diff=1197146Phabricator2018-07-11T17:45:14Z<p>Mcote: Update intro; link to Eng. WF page and new FAQ</p>
<hr />
<div>= Phabricator at Mozilla =<br />
<br />
Mozilla runs a Phabricator instance at https://phabricator.services.mozilla.com/, mainly for code review. It is currently the preferred solution for code review, and will be the ''sole'' code-review tool for Firefox by the end of 2018Q3; both [[EngineeringProductivity/Projects/MozReview|MozReview]] and Splinter will be decommissioned.<br />
<br />
Also see [[Lando]], an automatic code-landing system integrated with Phabricator.<br />
<br />
Phabricator and Lando are maintained by the [[Engineering Workflow]] team.<br />
<br />
= Documentation =<br />
<br />
User documentation for Mozilla's Phabricator instance is available on [http://moz-conduit.readthedocs.io/en/latest/ Read the Docs]. There is also a [[/FAQ|user FAQ]] for Phabricator and Lando.<br />
<br />
= Operations and Testing =<br />
<br />
* [[Phabricator/UpgradeProcess|Upgrade process]]<br />
* [[Phabricator/TestPlan|Test plan]]<br />
<br />
= Background =<br />
== Why the change? ==<br />
<br />
Code review is a critical part of the Firefox engineering process but hasn’t changed much since Mozilla’s early days. Our home-developed tools have worked well for us but are increasingly dependent upon scarce resources to maintain, build and customize. Using our own tool, something that isn’t used by other organizations, also makes onboarding new people, staff and volunteers much more time-consuming than it needs to be.<br />
<br />
We are confident the short-term/immediate costs incurred—standing up a new tool, having to shift expectations and refactor workflows—will be more than paid back with surplus time and energy available for process automation (and later, with faster onboarding).<br />
<br />
== Why did we choose Differential? ==<br />
<br />
Differential, originally developed at Facebook and currently used by many organizations, both open- and closed-source, has been trialled by several teams at Mozilla over the last few months. Although no code review tool is perfect, we believe it addresses several of the deficiencies in Review Board and is better suited to the Firefox engineering process. It is also an opportunity to decouple our automation pieces in order to focus on them after Differential’s launch, where we believe we will have a greater impact to Firefox development.<br />
<br />
== What will go out in the initial launch? ==<br />
<br />
# Deployment of a central Differential (code review) installation, supported by CloudOps, along with supporting tools like Diffusion (repository browser) and Herald (event-driven notifications). We will continue to use our Bugzilla instance, bugzilla.mozilla.org (aka BMO), for issue tracking for the foreseeable future.<br />
# Lightweight integration of Differential with BMO. This will include<br />
#* BMO integration, as discussed above.<br />
#* Integration with the Autoland service, which is currently used for around 50% of commits to mozilla-central and an integral part of the Quantum Stylo project.<br />
<br />
== What will happen to Splinter and MozReview? ==<br />
<br />
After a short trial period, MozReview will be shut down, and Splinter will be turned off for the main Firefox products on BMO: Core, Firefox, and Toolkit. Contribution guides and documentation will be updated to refer to Phabricator for code-change submissions. The exact archival procedures are will be figured out soon.<br />
<br />
== Will I be able to request customizations to Differential? ==<br />
<br />
We plan to limit customizations, but not to zero. We’re making this change (to using a third-party tool) to reduce the support burden on internal teams. The fewer customizations we make the more that happens. Any customizations will generally use Phabricator’s Conduit API; extensions will be limited to changes that are not possible to<br />
implement via the API. We have no intention of forking any Phabricator tools.<br />
<br />
== How will I get patches/commits up for review? ==<br />
<br />
To begin with, we will keep to the general Phabricator workflow, including use of the Arcanist command-line tool, although we will likely provide easy installation and some abstraction via mach and MozillaBuild.<br />
<br />
After initial launch, we will build support for "push to review", that is, a commit-based system, similar to MozReview's approach. <br />
<br />
== Where will the flags for feedback/review/ui-review be? ==<br />
<br />
We’re going with the review flow built into Differential, which does not support multiple types of flags as Bugzilla’s attachment-flag system does. However, the actions that a reviewer can perform in Differential are more straightforward: rather than setting “r+” or “r-”, Differential’s options include “resign as reviewer”, “request<br />
changes”, and “accept revision”, which roughly map to clearing a r? flag, setting r-, and setting r+, respectively. Differential also distinguishes between a reviewer and a “blocking reviewer”, which could be seen as requesting feedback versus requesting review. Finally, compared to Bugzilla, Differential has a clearer indication of the current state of the reviews on a revision and what needs to happen.<br />
<br />
We’re using the opportunity presented by switching to a new code review tool to try out this simpler approach, which will particularly benefit new contributors. This is possibly the biggest change in process, and we know it may take some time to get used to.<br />
<br />
== Will I be able to push to review? ==<br />
<br />
Most likely, some time after initial launch.<br />
<br />
A commit-based system offers many advantages over a patch-based system, mostly because of the metadata, including history, preserved in commits. The ability to use hg/git’s “push” command to submit patches for review was also one of the much-appreciated aspects of MozReview. However, it’s a tricky thing to get right. We never solved the problem of confidential patch review in MozReview, since mapping Bugzilla’s security groups to the Mercurial review repository is rather difficult. Our support for micro-/stacked commits was also a bit more confusing than we liked.<br />
<br />
In the interests of doing a staggered launch and iterative development, and so users can start to get used to Differential as soon as possible, the initial launch will only support the standard Phabricator methods for submitting changes, that is, arc (and via the web UI, although that is less convenient and powerful). We will build a commit-based system around Phabricator soon after.<br />
<br />
== Will there be alternative code review tools available? ==<br />
<br />
No single tool is going to make everyone happy, but we don’t plan to support multiple tools.<br />
<br />
== What will the team do if they won’t be working on the tool itself? ==<br />
<br />
In addition to (re)building a commit-based system, we have plenty of things lined up already. Here are a few:<br />
<br />
* Linting upon patch submission.<br />
* Fully automated landings. Signal your intention to land a patch when you submit it, and after it gets reviewed by authorized developers Autoland will land it automatically.<br />
* Automatic conflict detection, indicating if a patch can’t be cleanly applied to the tree before you try to land it, or even before it’s reviewed.<br />
* Automatic, intelligent Try runs based on what parts of the code were modified.<br />
* Tracking a patch through its lifecycle: review, landing, merges, uplifts, and any backouts along the way.<br />
<br />
The pattern here is that these are automated analyses and actions that are part of a pipeline from patch submission to review to landing to<br />
release. These are the steps in the engineering process that are largely unique to Firefox’s complex and highly scaled nature. Our team<br />
believes that the biggest positive impact to developer productivity lies in this area.<br />
<br />
As noted above, these enhancements are either dependent on or greatly simplified by a commit-based model, which will we (re)build first.<br />
<br />
== We are we rebuilding parts of MozReview around Phabricator? ==<br />
<br />
MozReview started out as an experiment and prototype that simultaneously delivered a new code review tool with some process automation. A lot of this automation was built into Review Board extensions and, later, into a custom fork. We also customized the tool to mimic the BMO patch review process as closely as we could.<br />
<br />
Making major changes to Review Board and tightly coupling process automation to it resulted in a heavily constrained development environment and increasing maintenance burdens. Last year we came to the realization that a major architectural change and a refocusing of priorities were overdue.<br />
<br />
At the same time we took a hard look at Review Board and concluded that, even without the added complexities of our customizations, it had some problems and deficiencies that were rather difficult to fix, including loading times, inaccuracies and omissions in diffs, and basic UI structure. Taking a look at alternative code-review solutions, of which none are perfect, it seems that Differential better meets Firefox engineering’s needs and already has some supporters at Mozilla.</div>Mcotehttps://wiki.mozilla.org/index.php?title=WeeklyUpdates/2018-07-09&diff=1196827WeeklyUpdates/2018-07-092018-07-07T00:40:35Z<p>Mcote: /* Speakers */ Phabricator/Lando Training Video</p>
<hr />
<div><br />
{{WeeklyUpdateNav}}<br />
* Every Monday @ 11:00am Pacific Time (19:00 UTC) <br />
* https://air.mozilla.org/channels/project-meeting/ to watch and listen<br />
* join irc.mozilla.org #airmozilla for backchannel discussion<br />
* Presenters only: Vidyo room "Brownbags". Do '''not''' use this room if you're not planning to speak. <br />
{{conf|8600}}<br />
** If you plan on presenting, please join the Vidyo BrownBags 20 minutes prior to the start of the meeting and announce to the A/V Technicians that you will be speaking so that they can confirm your Audio and Video.<br />
<br />
__TOC__<br />
<br />
= All-hands Status Meeting Agenda =<br />
<br />
Items in this section will be shared during the live all-hand status meeting.<br />
<br />
== Friends of Mozilla [[Image:Tree.gif|Friends of Mozilla]] ==<br />
<br />
== Upcoming Events ==<br />
<br />
=== This Week ===<br />
<br />
=== Monday, {{#time:d F|{{SUBPAGENAME}}}} ===<br />
<br />
=== Tuesday, {{#time:d F|{{SUBPAGENAME}} +1 day}} ===<br />
<br />
=== Wednesday, {{#time:d F|{{SUBPAGENAME}} +2 days}} ===<br />
* '''[https://indiewebcamp.com/events/2018-07-11-homebrew-website-club Homebrew Website Club Meetup]''' (nearly every Wednesday somewhere)<br/><strong>Be a part of the open web with your own website.</strong><br />
** '''Nürnberg (GERMANY)''', <br/>'''Virtual EU (UTC+1)''', <br/>'''San Francisco''' (@[[MozSF]] commons hosted by Tantek)<br />
** 17:30-18:30 Quiet Writing Hour, finish that blog post, wiki edit, etc.!<br />
** 18:30-19:30 IndieWeb meetup, demos, & hack night <blockquote><p>Create or update your personal web site!<br/>Share what you've gotten working.</p><p>Join a community with like-minded interests. <br/>Bring friends that want a personal site!</p></blockquote> Any questions? See '''[https://indiewebcamp.com/events/2018-07-11-homebrew-website-club the wiki page for details]''' <br/>or join IRC: https://indieweb.org/discuss<br />
<br />
=== Thursday, {{#time:d F|{{SUBPAGENAME}} +3 days}} ===<br />
<br />
=== Friday, {{#time:d F|{{SUBPAGENAME}} +4 days}} ===<br />
<br />
=== Saturday, {{#time:d F|{{SUBPAGENAME}} +5 days}} ===<br />
<br />
=== Sunday, {{#time:d F|{{SUBPAGENAME}} +6 days}} ===<br />
<br />
=== Next Week ===<br />
<br />
== Speakers ==<br />
<br />
The limit is '''3 minutes per topic'''. It's like a lightning talk, but don't feel that you have to have slides in order to make a presentation. If you plan on showing a video, you need to contact the Air Mozilla team before the day of the meeting or you will be deferred to the next week. The meeting is streamed in a 4:3 format in order to allow for split screen. If your slides are 16:9 "widescreen" format, please indicate in the "Sharing" column below.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! [https://mozillians.org/u/USERNAME Presenter]<br />
! Title<br />
! Topic<br />
! Location<br />
! Sharing<br />
! Media<br />
! More Details<br />
|-<br />
| Who Are You?<br />
| What Do You Do?<br />
| What are you going to talk about?<br />
| Where are you presenting from? (Moz Space, your house, space)<br />
| Will you be sharing your screen? (yes/no, 4:3 or 16:9)<br />
| Links to slides or images you want displayed on screen<br />
| Link to where audience can find out more information<br />
|-<br />
| Mark C&ocirc;t&eacute;<br />
| Manager, Engineering Workflow<br />
| Phabricator/Lando Training Video<br />
| Remote<br />
| no<br />
| n/a<br />
| https://www.youtube.com/watch?v=3e-eaeeIDXk<br />
|-<br />
|}<br />
<br />
= Welcome! =<br />
<br />
Let's say hello to some new Mozillians! If you are not able to join the meeting live, you can add a link to a short video introducing yourself.<br />
<br />
{| class="fullwidth-table wikitable"<br />
|-<br />
! ''Who is being introduced?''<br />
! ''Who are you? (the introducer)''<br />
! ''Where are you doing the introduction?''<br />
! ''Where are they from?''<br />
! ''How will they be part of Mozilla?''<br />
|-<br />
<!-- Insert new rows here --><br />
|-<br />
| Their Name<br />
| Your Name<br />
| Intro location<br />
| Their Location<br />
| Their Role<br />
|-<br />
|}<br />
<br />
<br />
[[Category:Weekly Updates]]<br />
[[Category:Meeting Notes]]</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194695Engineering Workflow/Road Map2018-05-29T02:36:07Z<p>Mcote: </p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Vanilla (cinnabar-less) Git support for mozilla-central ===<br />
<br />
git-cinnabar was created to allow developers to use Git to interact with Mercurial, mainly [https://hg.mozilla.org|hg.mozilla.org]. It has some downsides, however, such as being a bit tricky to install. Ideally developers would be able to use vanilla Git to contribute to Firefox.<br />
<br />
If we view Phabricator and Lando as a conduit to getting code into mozilla-central, then ultimately VCS clients would only need to talk to Phabricator. Phabricator natively supports both Mercurial and Git<sup>[[#vcs-parent-note|1]]</sup>, and full Lando support means that developers will not need to talk to hg.mozilla.org directly. We just need to ensure that the user experience of submitting a patch in progress to Try remains as straightforward as it is today.<br />
<br />
Impact:<br />
* No need to maintain nor educate people on git-cinnabar.<br />
* End to unproductive VCS debates.<br />
* Solidifies Phabricator-Lando as the conduit to hg.mozilla.org; this consolidation will make it easier to add more services and automation to the commit pipeline.<br />
<br />
<div id="vcs-parent-note><small><br />
1. There is one wrinkle in supporting two VCSes for the same repository: like figuring out parent commits when a different VCS is used to pull down commits; see {{bug|1443375}} for how this was solved with git-cinnabar.</small></div><br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194694Engineering Workflow/Road Map2018-05-29T02:31:01Z<p>Mcote: /* cinnabar-less Git(Hub) gecko-dev support */ git support</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Vanilla (cinnabar-less) Git support ===<br />
<br />
git-cinnabar was created to allow developers to use Git to interact with Mercurial, mainly [https://hg.mozilla.org|hg.mozilla.org]. It has some downsides, however, such as being a bit tricky to install. Ideally developers would be able to use vanilla Git to contribute to Firefox.<br />
<br />
If we view Phabricator and Lando as a conduit to getting code into mozilla-central, then ultimately VCS clients would only need to talk to Phabricator. Phabricator natively supports both Mercurial and Git<sup>[[#vcs-parent-note|1]]</sup>, and full Lando support means that developers will not need to talk to hg.mozilla.org directly. We just need to ensure that the user experience of submitting a patch in progress to Try remains as straightforward as it is today.<br />
<br />
Impact:<br />
* No need to maintain nor educate people on git-cinnabar.<br />
* End to unproductive VCS debates.<br />
* Solidifies Phabricator-Lando as the conduit to hg.mozilla.org; this consolidation will make it easier to add more services and automation to the commit pipeline.<br />
<br />
<div id="vcs-parent-note><small><br />
1. There is one wrinkle in supporting two VCSes for the same repository: like figuring out parent commits when a different VCS is used to pull down commits; see {{bug|1443375}} for how this was solved with git-cinnabar.</small></div><br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194693Engineering Workflow/Road Map2018-05-29T02:18:07Z<p>Mcote: /* Future */ WIP: git support</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
git-cinnabar was created to allow developers to use Git to interact with Mercurial, mainly [https://hg.mozilla.org]. It has some downsides, however, such as being a bit tricky to install. Ideally developers would be able to use vanilla Git to contribute to Firefox.<br />
<br />
If we view Phabricator and Lando as a conduit to getting code into mozilla-central, then ultimately VCS clients would only need to talk to Phabricator. Phabricator natively supports both Mercurial and Git<ref>There is one wrinkle in supporting two VCSes for the same repository: like figuring out parent commits when a different VCS is used to pull down commits; see {{bug|1443375}} for how this was solved with git-cinnabar.</ref><br />
<br />
<references /><br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194692Engineering Workflow/Road Map2018-05-29T02:00:49Z<p>Mcote: include revision-stack landings in "Lando for All"</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss three important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions, and Try, and revision stacks. The latter two were included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision and can easily land multiple revisions at once.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194691Engineering Workflow/Road Map2018-05-29T01:58:41Z<p>Mcote: move BMO Auth0 integration into "Next"</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss two important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions and Try. The latter was included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194690Engineering Workflow/Road Map2018-05-29T01:56:57Z<p>Mcote: Revise impact of "Lando for All"</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss two important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions and Try. The latter was included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision.<br />
* Clarity of tooling and better maintainability, as we can then eliminate patch review in BMO.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1194689Engineering Workflow/Road Map2018-05-29T01:55:11Z<p>Mcote: lando enhancements</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Next ==<br />
<br />
=== Lando for All ===<br />
<br />
The initial version of Lando will miss two important features required to be a complete replace for pushing directly to Firefox repositories: support for confidential revisions and Try. The latter was included in MozReview's Autoland system. The former was notably lacking in MozReview.<br />
<br />
Impact:<br />
* Efficiency: users can easily send off a Try job from a Phabricator revision.<br />
* Less context switching.<br />
* Information clarity: discoverable record of results of Try pushes for a given revision.<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193598Engineering Workflow/Road Map2018-05-11T01:36:00Z<p>Mcote: specify this is the initial release of lando</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando initial release ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193589Engineering Workflow/Road Map2018-05-10T19:01:23Z<p>Mcote: transplant</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Transplant internal improvements ===<br />
<br />
The Transplant service is the engine that takes diffs from Phabricator (via Lando) and, until its retirement, MozReview and lands them in the destination repository on behalf of a user. There is some design debt in its architecture and deployability that will benefit future work on related services (particularly Lando).<br />
<br />
Impact:<br />
* Lower maintenance costs.<br />
* Easier to develop locally.<br />
* Better support from operations.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193587Engineering Workflow/Road Map2018-05-10T18:33:03Z<p>Mcote: Formatting consistency</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency.<br />
* Faster checkouts to enable shorter end to end times for local and CI builds.<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact:<br />
* Reduce the incidence of clobber builds.<br />
* Faster incremental builds.<br />
* Secure and IT supported mechanism for faster local builds in offices.<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups.<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data.<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193586Engineering Workflow/Road Map2018-05-10T18:32:16Z<p>Mcote: Auth0</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
=== Hg scalability and efficiency ===<br />
<br />
Implement hgweb mirroring in AWS and upstream remotefilelog extension for hg<br />
<br />
Impact:<br />
* Multi-region redundancy and autoscaling for hgweb servers for additional resiliency<br />
* Faster checkouts to enable shorter end to end times for local and CI builds<br />
<br />
=== Build backend ===<br />
<br />
Implement a new build backend for both local and CI builds. Deploy a new distributed sccache system written in Rust to enable fast, secure local builds in offices. Implement local build telemetry that submits data to the generic data ingestion pipeline to allow us to identify and reduce inefficiencies in local builds.<br />
<br />
Impact<br />
* Reduce the incidence of clobber builds<br />
* Faster incremental builds<br />
* Secure and IT supported mechanism for faster local builds in offices<br />
<br />
== Future ==<br />
<br />
=== BMO Auth0 Integration ===<br />
<br />
Our Bugzilla instance will be tied into Mozilla's Auth0 IAM system, which will allow the linking of BMO accounts to LDAP, Mozillians, etc.<br />
<br />
Impact:<br />
* Easily identify employees, NDAed volunteers, and other contributor groups<br />
* Applications integrated with BMO, e.g. Phabricator, can access users' LDAP accounts and other Mozillian data<br />
* Applications already integrated into Mozilla's IAM system can access Bugzilla user data<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Run tests from source directory in local and ci builds ===<br />
<br />
=== Overhauling release repositories and build configurations to use named branches ===<br />
<br />
=== Support for platforms other than Linux for new build backend ===<br />
<br />
=== Cross-compile a Windows build with clang-cl from Linux ===<br />
<br />
=== Artifact caching experiments for builds ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193569Engineering Workflow/Road Map2018-05-09T23:34:51Z<p>Mcote: /* Engineering Workflow Road Map */ BMO usability</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
=== BMO usability ===<br />
<br />
Implement a number of long-awaited UX enhancements, including MarkDown, full UTF-8 support, and quick edits.<br />
<br />
Impact:<br />
* User delight!<br />
* Less friction for new users.<br />
* Better expressibility and accuracy in comments.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193272Engineering Workflow/Road Map2018-05-03T19:07:45Z<p>Mcote: /* Lando */ Better statements of impact</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing offers an easier way to land code and minimal context switching from reviewing code.<br />
* Queued landings due to tree closures means developers don't have to be around when they open to land their code.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193270Engineering Workflow/Road Map2018-05-03T18:59:51Z<p>Mcote: /* Phabricator integration */ minor tweaks to impact</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing which can be initiated by anyone with appropriate SCM access.<br />
* Queues landings if the trees are closed.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193269Engineering Workflow/Road Map2018-05-03T18:59:17Z<p>Mcote: /* Vendor manifests */ better statements of impact</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review, which allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing which can be initiated by anyone with appropriate SCM access.<br />
* Queues landings if the trees are closed.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Easier to identify and find third-party code in mozilla-central.<br />
* Easier to determine metadata about third-party code, including original source and current revision.<br />
* Easier to update third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lando Git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193222Engineering Workflow/Road Map2018-05-02T23:45:35Z<p>Mcote: /* Current */ Lando</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
* One sole tool for review, which allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Lando ===<br />
<br />
[https://lando.services.mozilla.com Lando] is the new automatic code-landing tool integrated with Phabricator. It is (or at least will be) functionally similar to MozReview's Autoland but is designed to be more maintainable and extensible by being less tightly coupled to the review tool.<br />
<br />
Impact:<br />
* One-button landing which can be initiated by anyone with appropriate SCM access.<br />
* Queues landings if the trees are closed.<br />
* Becomes a common gateway to mozilla-central (and other repos) which allows more process and security improvements (see below).<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Third-party code in mozilla-central is obvious and easy to find.<br />
* Standard processes to increase predictability of updates to third-party code.<br />
* Tools to ease updates to third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193221Engineering Workflow/Road Map2018-05-02T23:42:19Z<p>Mcote: Eliminate some redundancy</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact:<br />
<br />
* One sole tool for review, which allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Third-party code in mozilla-central is obvious and easy to find.<br />
* Standard processes to increase predictability of updates to third-party code.<br />
* Tools to ease updates to third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193220Engineering Workflow/Road Map2018-05-02T23:41:57Z<p>Mcote: vendor manifests impact</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact: Switching to Phabricator has a number of benefits:<br />
<br />
* One sole tool for review, which allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
Impact:<br />
* Third-party code in mozilla-central is obvious and easy to find.<br />
* Standard processes to increase predictability of updates to third-party code.<br />
* Tools to ease updates to third-party code.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193219Engineering Workflow/Road Map2018-05-02T23:39:59Z<p>Mcote: Split into current & future, add section on Phabricator</p>
<hr />
<div>= Engineering Workflow Road Map =<br />
<br />
These are the improvements and new services we are currently working on and others that we are considering for the near future (1-2 years). It is subject to change.<br />
<br />
== Current ==<br />
<br />
=== Phabricator integration ===<br />
<br />
Although our [[Phabricator]] instance has been up since September 2017, there has been ongoing work to integrate it into our tools, most notably [[BMO]]. There is a tracking bug ({{bug|1381498}}) for the remaining work before we announce general availability and start encouraging people to move over.<br />
<br />
The last remaining item of note is forking Arcanist so that it works with git-cinnabar ({{bug|1443375}}).<br />
<br />
Impact: Switching to Phabricator has a number of benefits:<br />
<br />
* One sole tool for review, which allows the Engineering Workflow to concentrate its efforts, and eliminates the need for contributors to learn several tools.<br />
* A more intuitive interface than BMO and MozReview, with a contemporary look to appeal to new contributors.<br />
* Some integration with existing tools and processes, balancing complexity and disruption.<br />
* Excellent support from Phabricator's developers ([https://phacility.com Phacility]) and a large user community.<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the tracking bug ({{bug|1454867}}) for progress.<br />
<br />
== Future ==<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193120Engineering Workflow/Road Map2018-05-01T19:51:00Z<p>Mcote: /* Engineering Workflow Road Map */</p>
<hr />
<div>== Engineering Workflow Road Map ==<br />
<br />
These are the improvements and new services we are currently considering for the near future (1-2 years). It is subject to change.<br />
<br />
=== Cinnab-arc ===<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the [https://bugzilla.mozilla.org/show_bug.cgi?id=1454867 tracking bug] for progress.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow/Road_Map&diff=1193118Engineering Workflow/Road Map2018-05-01T19:50:41Z<p>Mcote: Created page with "== Engineering Workflow Road Map == These are the improvements and new services we are currently considering for the near future (1-2 years). It is subject to change. ====..."</p>
<hr />
<div>== Engineering Workflow Road Map ==<br />
<br />
These are the improvements and new services we are currently considering for the near future (1-2 years). It is subject to change.<br />
<br />
==== Cinnab-arc ===<br />
<br />
=== Vendor manifests ===<br />
<br />
Provide a common structure, process, and tools for managing third-party code in mozilla-central. An [https://groups.google.com/forum/?pli=1#!topic/mozilla.dev.platform/-B8MECCeJnM Intent to Require] was posted to dev.platform on 2018/04/10 and finalized on 2018/10/18. Follow the [https://bugzilla.mozilla.org/show_bug.cgi?id=1454867 tracking bug] for progress.<br />
<br />
=== Enforced reviewers ===<br />
<br />
=== Intent-to-land ===<br />
<br />
=== Lando Try support ===<br />
<br />
=== Lando confidential-revision support ===<br />
<br />
=== Lando stacked landing ===<br />
<br />
=== cinnabar-less Git(Hub) gecko-dev support ===<br />
<br />
=== Lando headless client API support ===<br />
<br />
=== Lando and Phabricator backout support ===<br />
<br />
=== Transplant service improvements ===<br />
<br />
=== Lango git support ===<br />
<br />
=== Auth0 integration with BMO ===<br />
<br />
=== Markdown in BMO ===</div>Mcotehttps://wiki.mozilla.org/index.php?title=Engineering_Workflow&diff=1193096Engineering Workflow2018-05-01T17:59:08Z<p>Mcote: /* Our systems */ link to build docs, road map</p>
<hr />
<div>== Our mission ==<br />
<br />
The Engineering Workflow team exists to improve the quality, clarity, and efficiency of Firefox development through the integration and development of tools and automation.<br />
<br />
== Our team ==<br />
<br />
We are generalists who work on everything from web apps to VCS deployments and integrations to build systems. We are part of the Engineering Operations department.<br />
<br />
== Our systems ==<br />
<br />
The major systems for which Engineering Workflow is responsible includes the following:<br />
<br />
* [[BMO|bugzilla.mozilla.org (BMO)]]<br />
* [[Phabricator]]<br />
* [https://lando.services.mozilla.com Lando]<br />
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build Firefox build]<br />
* [https://hg.mozilla.org hg.mozilla.org]<br />
* [[EngineeringProductivity/Projects/MozReview|MozReview]] (to be decommissioned)<br />
* [[Auto-tools/Projects/Pulse|Pulse & PulseGuardian]]<br />
<br />
We have a [[/Road Map|road map]] of future work to these and new systems.</div>Mcote