%global _empty_manifest_terminate_build 0 Name: python-MozPhab Version: 1.4.3 Release: 1 Summary: Phabricator review submission/management tool. License: Mozilla Public License Version 2.0 ================================== 1. Definitions -------------- 1.1. "Contributor" means each individual or legal entity that creates, contributes to the creation of, or owns Covered Software. 1.2. "Contributor Version" means the combination of the Contributions of others (if any) used by a Contributor and that particular Contributor's Contribution. 1.3. "Contribution" means Covered Software of a particular Contributor. 1.4. "Covered Software" means Source Code Form to which the initial Contributor has attached the notice in Exhibit A, the Executable Form of such Source Code Form, and Modifications of such Source Code Form, in each case including portions thereof. 1.5. "Incompatible With Secondary Licenses" means (a) that the initial Contributor has attached the notice described in Exhibit B to the Covered Software; or (b) that the Covered Software was made available under the terms of version 1.1 or earlier of the License, but not also under the terms of a Secondary License. 1.6. "Executable Form" means any form of the work other than Source Code Form. 1.7. "Larger Work" means a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software. 1.8. "License" means this document. 1.9. "Licensable" means having the right to grant, to the maximum extent possible, whether at the time of the initial grant or subsequently, any and all of the rights conveyed by this License. 1.10. "Modifications" means any of the following: (a) any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or (b) any new file in Source Code Form that contains any Covered Software. 1.11. "Patent Claims" of a Contributor means any patent claim(s), including without limitation, method, process, and apparatus claims, in any patent Licensable by such Contributor that would be infringed, but for the grant of the License, by the making, using, selling, offering for sale, having made, import, or transfer of either its Contributions or its Contributor Version. 1.12. "Secondary License" means either the GNU General Public License, Version 2.0, the GNU Lesser General Public License, Version 2.1, the GNU Affero General Public License, Version 3.0, or any later versions of those licenses. 1.13. "Source Code Form" means the form of the work preferred for making modifications. 1.14. "You" (or "Your") means an individual or a legal entity exercising rights under this License. For legal entities, "You" includes any entity that controls, is controlled by, or is under common control with You. For purposes of this definition, "control" means (a) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (b) ownership of more than fifty percent (50%) of the outstanding shares or beneficial ownership of such entity. 2. License Grants and Conditions -------------------------------- 2.1. Grants Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: (a) under intellectual property rights (other than patent or trademark) Licensable by such Contributor to use, reproduce, make available, modify, display, perform, distribute, and otherwise exploit its Contributions, either on an unmodified basis, with Modifications, or as part of a Larger Work; and (b) under Patent Claims of such Contributor to make, use, sell, offer for sale, have made, import, and otherwise transfer either its Contributions or its Contributor Version. 2.2. Effective Date The licenses granted in Section 2.1 with respect to any Contribution become effective for each Contribution on the date the Contributor first distributes such Contribution. 2.3. Limitations on Grant Scope The licenses granted in this Section 2 are the only rights granted under this License. No additional rights or licenses will be implied from the distribution or licensing of Covered Software under this License. Notwithstanding Section 2.1(b) above, no patent license is granted by a Contributor: (a) for any code that a Contributor has removed from Covered Software; or (b) for infringements caused by: (i) Your and any other third party's modifications of Covered Software, or (ii) the combination of its Contributions with other software (except as part of its Contributor Version); or (c) under Patent Claims infringed by Covered Software in the absence of its Contributions. This License does not grant any rights in the trademarks, service marks, or logos of any Contributor (except as may be necessary to comply with the notice requirements in Section 3.4). 2.4. Subsequent Licenses No Contributor makes additional grants as a result of Your choice to distribute the Covered Software under a subsequent version of this License (see Section 10.2) or under the terms of a Secondary License (if permitted under the terms of Section 3.3). 2.5. Representation Each Contributor represents that the Contributor believes its Contributions are its original creation(s) or it has sufficient rights to grant the rights to its Contributions conveyed by this License. 2.6. Fair Use This License is not intended to limit any rights You have under applicable copyright doctrines of fair use, fair dealing, or other equivalents. 2.7. Conditions Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1. 3. Responsibilities ------------------- 3.1. Distribution of Source Form All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License. You must inform recipients that the Source Code Form of the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License. You may not attempt to alter or restrict the recipients' rights in the Source Code Form. 3.2. Distribution of Executable Form If You distribute Covered Software in Executable Form then: (a) such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and (b) You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients' rights in the Source Code Form under this License. 3.3. Distribution of a Larger Work You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s). 3.4. Notices You may not remove or alter the substance of any license notices (including copyright notices, patent notices, disclaimers of warranty, or limitations of liability) contained within the Source Code Form of the Covered Software, except that You may alter any license notices to the extent required to remedy known factual inaccuracies. 3.5. Application of Additional Terms You may choose to offer, and to charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Covered Software. However, You may do so only on Your own behalf, and not on behalf of any Contributor. You must make it absolutely clear that any such warranty, support, indemnity, or liability obligation is offered by You alone, and You hereby agree to indemnify every Contributor for any liability incurred by such Contributor as a result of warranty, support, indemnity or liability terms You offer. You may include additional disclaimers of warranty and limitations of liability specific to any jurisdiction. 4. Inability to Comply Due to Statute or Regulation --------------------------------------------------- If it is impossible for You to comply with any of the terms of this License with respect to some or all of the Covered Software due to statute, judicial order, or regulation then You must: (a) comply with the terms of this License to the maximum extent possible; and (b) describe the limitations and the code they affect. Such description must be placed in a text file included with all distributions of the Covered Software under this License. Except to the extent prohibited by statute or regulation, such description must be sufficiently detailed for a recipient of ordinary skill to be able to understand it. 5. Termination -------------- 5.1. The rights granted under this License will terminate automatically if You fail to comply with any of its terms. However, if You become compliant, then the rights granted under this License from a particular Contributor are reinstated (a) provisionally, unless and until such Contributor explicitly and finally terminates Your grants, and (b) on an ongoing basis, if such Contributor fails to notify You of the non-compliance by some reasonable means prior to 60 days after You have come back into compliance. Moreover, Your grants from a particular Contributor are reinstated on an ongoing basis if such Contributor notifies You of the non-compliance by some reasonable means, this is the first time You have received notice of non-compliance with this License from such Contributor, and You become compliant prior to 30 days after Your receipt of the notice. 5.2. If You initiate litigation against any entity by asserting a patent infringement claim (excluding declaratory judgment actions, counter-claims, and cross-claims) alleging that a Contributor Version directly or indirectly infringes any patent, then the rights granted to You by any and all Contributors for the Covered Software under Section 2.1 of this License shall terminate. 5.3. In the event of termination under Sections 5.1 or 5.2 above, all end user license agreements (excluding distributors and resellers) which have been validly granted by You or Your distributors under this License prior to termination shall survive termination. ************************************************************************ * * * 6. Disclaimer of Warranty * * ------------------------- * * * * Covered Software is provided under this License on an "as is" * * basis, without warranty of any kind, either expressed, implied, or * * statutory, including, without limitation, warranties that the * * Covered Software is free of defects, merchantable, fit for a * * particular purpose or non-infringing. The entire risk as to the * * quality and performance of the Covered Software is with You. * * Should any Covered Software prove defective in any respect, You * * (not any Contributor) assume the cost of any necessary servicing, * * repair, or correction. This disclaimer of warranty constitutes an * * essential part of this License. No use of any Covered Software is * * authorized under this License except under this disclaimer. * * * ************************************************************************ ************************************************************************ * * * 7. Limitation of Liability * * -------------------------- * * * * Under no circumstances and under no legal theory, whether tort * * (including negligence), contract, or otherwise, shall any * * Contributor, or anyone who distributes Covered Software as * * permitted above, be liable to You for any direct, indirect, * * special, incidental, or consequential damages of any character * * including, without limitation, damages for lost profits, loss of * * goodwill, work stoppage, computer failure or malfunction, or any * * and all other commercial damages or losses, even if such party * * shall have been informed of the possibility of such damages. This * * limitation of liability shall not apply to liability for death or * * personal injury resulting from such party's negligence to the * * extent applicable law prohibits such limitation. Some * * jurisdictions do not allow the exclusion or limitation of * * incidental or consequential damages, so this exclusion and * * limitation may not apply to You. * * * ************************************************************************ 8. Litigation ------------- Any litigation relating to this License may be brought only in the courts of a jurisdiction where the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction, without reference to its conflict-of-law provisions. Nothing in this Section shall prevent a party's ability to bring cross-claims or counter-claims. 9. Miscellaneous ---------------- This License represents the complete agreement concerning the subject matter hereof. If any provision of this License is held to be unenforceable, such provision shall be reformed only to the extent necessary to make it enforceable. Any law or regulation which provides that the language of a contract shall be construed against the drafter shall not be used to construe this License against a Contributor. 10. Versions of the License --------------------------- 10.1. New Versions Mozilla Foundation is the license steward. Except as provided in Section 10.3, no one other than the license steward has the right to modify or publish new versions of this License. Each version will be given a distinguishing version number. 10.2. Effect of New Versions You may distribute the Covered Software under the terms of the version of the License under which You originally received the Covered Software, or under the terms of any subsequent version published by the license steward. 10.3. Modified Versions If you create software not governed by this License, and you want to create a new license for such software, you may create and use a modified version of this License if you rename the license and remove any references to the name of the license steward (except to note that such modified license differs from this License). 10.4. Distributing Source Code Form that is Incompatible With Secondary Licenses If You choose to distribute Source Code Form that is Incompatible With Secondary Licenses under the terms of this version of the License, the notice described in Exhibit B of this License must be attached. Exhibit A - Source Code Form License Notice ------------------------------------------- This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/. If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice. You may add additional accurate notices of copyright ownership. Exhibit B - "Incompatible With Secondary Licenses" Notice --------------------------------------------------------- This Source Code Form is "Incompatible With Secondary Licenses", as defined by the Mozilla Public License, v. 2.0. URL: https://pypi.org/project/MozPhab/ Source0: https://mirrors.nju.edu.cn/pypi/web/packages/fa/18/1ef19c49c0707dc2819a8af8cf3ba87cdc1a791b96c258b955659aad9487/MozPhab-1.4.3.tar.gz BuildArch: noarch Requires: python3-distro Requires: python3-glean-sdk Requires: python3-packaging Requires: python3-hglib Requires: python3-sentry-sdk Requires: python3-setuptools Requires: python3-colorama Requires: python3-importlib-metadata %description # moz-phab Phabricator CLI from Mozilla to support submission of a series of commits. ## Installation `moz-phab` can be installed with `pip3 install MozPhab`. For detailed installation instructions please see: - [Windows Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-windows.html) - [Linux Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-linux.html) - [macOS Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-macos.html) `moz-phab` will periodically check for updates and seamlessly install the latest release when available. To force update `moz-phab`, run `moz-phab self-update`. ### Changelog Changelog is available on the [MozPhab page on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog). ## Configuration `moz-phab` has an INI style configuration file to control defaults: `~/.moz-phab-config` This file will be created if it doesn't exist. ```ini [ui] no_ansi = False [vcs] safe_mode = False [git] remote = command_path = [hg] command_path = [submit] auto_submit = False always_blocking = False warn_untracked = True [patch] apply_to = base create_bookmark = True create_topic = False always_full_stack = False [updater] self_last_check = 0 self_auto_update = True get_pre_releases = False [error_reporting] report_to_sentry = True ``` - `ui.no_ansi` : Never use ANSI colours (default: auto-detected). - `vcs.safe_mode` : Use only safe VCS settings (default: `False`). Use `--safe-mode` option to switch it on for a one-time usage. - `git.remote`: Comma separated string. Default remotes used to find the first unpublished commit. Default, empty string, means that a list of remotes will be read from `git remote` command. - `git.command_path`: Command path to Git binary. - `hg.command_path`: Command path to Mercurial binary. - `submit.auto_submit` : When `True` the confirmation prompt will be skipped (default: `False`). - `submit.always_blocking` : When `True` reviewers in commit descriptions will be marked as blocking. reviewers specified on the command line override this setting (default: `False`). - `submit.warn_untracked` : When `True` show a warning if there are uncommitted or untracked changes in the working directory (default: `True`). - `patch.apply_to` : [base/here] Where to apply the patches by default. If `"base"` `moz-phab` will look for the SHA1 in the first commit. If `"here"` - current commit/checkout will be used (default: base). - `patch.create_bookmark` : Affects only when patching a Mercurial repository. If `True` moz-phab will create a bookmark (based on the last revision number) for the new DAG branch point. - `patch.create_topic` : Affects only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If `True` moz-phab will create a topic (based on the last revision number) for the new DAG branch point. - `patch.always_full_stack` : When `False` and the patched revision has successors, moz-phab will ask if the whole stack should be patched instead. If `True` moz-phab will do it without without asking. - `updater.self_last_check` : Epoch timestamp (local timezone) indicating the last time an update check was performed for this script. set to `-1` to disable this check. - `self_auto_update` : When `True` moz-phab will auto-update if a new version is available. If `False` moz-phab will only warn about the new version. - `get_pre_releases` : When `True` moz-phab auto-update will fetch pre-releases if they are available, otherwise pre-releases will be ignored (default: `False`). - `error_reporting.report_to_sentry` : When `True` moz-phab will submit exceptions to Sentry so moz-phab devs can see unreported errors. ### Environment Variables `moz-phab` can also be configured via the following environment variables: - `DEBUG` : Enabled debugging output (default: disabled). - `MOZPHAB_NO_USER_CONFIG` : Do not read from or write to `~/.moz-phab-config` (default: disabled). ## Execution To get information about all available commands run ```shell moz-phab -h ``` All commands involving VCS (like `submit` and `patch`) might be used with a `--safe-mode` switch. It will run the VCS command with only chosen set of extensions. ### Submitting commits to Phabricator The simplest invocation is ```shell moz-phab [start_rev] [end_rev] ``` If no positional arguments (`start_rev`/`end_rev`) are given, the range of commits is automatically determined, starting with the first non-public, non-obsolete changeset (for Mercurial) or first unpublished commit (for Git) and ending with the currently checked-out changeset. If at least one argument is given `moz-phab` is following the underlying VCS's `log` behavior. The first argument is interpreted differently in Mercurial (as inclusive) and Git (exclusive). If only one argument is given the end of range is again interpreted as the currently checked-out changeset. If both arguments are given - the second one is interpreted as inclusive. Bug IDs and reviewers are parsed out of commit messages by default. You can set a reviewer as blocking by appending an exclamation mark to the reviewer's nick, e.g. `r=foo!`. If `submit.always_blocking` is set to `true` (see above), reviewers will always be set to blocking regardless. A bug ID can also be set *for every revision in the series* with the `--bug` option, which overrides any bug IDs in commit messages. Similarly, reviewers can be set *for every revision in the series* with `--reviewer` (regular reviewers) and/or `--blocker` (blocking reviewers), which again overrides any reviewers in commit messages. Run `moz-phab submit -h` for more options for submitting revisions. To submit updates to a commit series, run `moz-phab` in the same way with the same arguments, that is, specifying the full original range of commits. Note that, while inserting and amending commits should work fine, reordering commits is not yet supported, and deleting commits will leave the associated revisions open, which should be abandoned manually. See [bug 1481539](https://bugzilla.mozilla.org/show_bug.cgi?id=1481539) for planned fixes. Also note that "fix-up" commits are not yet supported; see [bug 1481542](https://bugzilla.mozilla.org/show_bug.cgi?id=1481542). ### Downloading a patch from Phabricator `moz-phab patch` allows patching an entire stack of revisions. The simplest invocation is ```shell moz-phab patch revision_id ``` To patch a stack ending with the revision `D123` run `moz-phab patch D123`. Diffs will be downloaded from Phabricator and applied using the underlying VCS (`import` for Mercurial or `apply` for Git). A commit for each revision will be created in a new bookmark or topic (Mercurial) or branch (Git). This behavior can be modified with the following options: - `--apply-to TARGET` Define the commit to which apply the patch: - `base` (default) find the base commit in the first ancestor of the revision, - `here` use the current commit, - `{NODE}` use a commit identified by SHA1 or (in Mecurial) revision number - `--raw` Print out the diffs of each revision starting from the oldest ancestor instead of applying to the repository. It can be used to patch the working directory with an external tool: `$ moz-phab patch D123 --raw | patch -p1`. `$ moz-phab patch D123 --raw | hg import`. `$ moz-phab patch D123 --raw | git am`. - `--no-commit` Use the `git apply` command (also for Mercurial repos) to patch the diffs. No commit or branch is created. - `--no-bookmark` : used only when patching a Mercurial repository. If not provided - `moz-phab` will create a bookmark (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-topic` : used only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If not provided and enabled in the configuration - `moz-phab` will create a topic (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-branch`: used only when patching a Git repository. If not provided - `moz-phab` will create a branch (based on the revision number). Otherwise commits will be added just on top of the *base commit* which might result in switching the repository to the 'detached HEAD' state. - `--skip-dependencies` : patch only one revision, ignore dependencies. - `--diff-id DIFF_ID`: used to specify a specific diff within a revision's history to pull. ### Reorganizing the stack `moz-phab reorg [start_rev] [end_rev]` allows you to reorganize the stack in Phabricator. If you've changed the local stack by adding, removing or moving the commits around, you need to change the parent/child relation of the revisions in Phabricator. `moz-phab reorg` command will compare the stack, display what will be changed and ask for permission before taking any action. This behavior can be modified with the following options: - `--no-abandon` Avoid abandoning revisions on Phabricator when they have been removed from the local stack. Only change the dependency relationships between revisions. ### Associating a commit to an existing phabricator revision `moz-phab` tracks which revision is associated with a commit using a line in the commit message. If you want to work on an existing revision from a different machine or environment, we recommend you [apply the existing revision from Phabricator using `moz-phab patch`](#downloading-a-patch-from-phabricator). If that isn't an option for whatever reason, you can associate a new commit to the same revision by adding a line similar to the following to the extended commit message: ```text Differential Revision: https://phabricator.services.mozilla.com/D[revision] ``` replacing `[revision]` with the identifier of your revision. ### Submitting an uplift request `moz-phab uplift` can be used to submit a patch for uplift to a release repository, bypassing the standard release train cycles. See [the Release Management wiki](https://wiki.mozilla.org/Release_Management/Feature_Uplift) for more details about uplifts. To see which trains can be submitted for an uplift request: ```shell moz-phab uplift --list-trains ``` `moz-phab uplift` uses the same syntax as `moz-phab submit`. To submit an uplift request against mozilla-beta: ```shell moz-phab uplift start_rev end_rev --train beta ``` When you submit an uplift within a unified repo (i.e., `mozilla-unified` or `gecko-dev`), `moz-phab uplift` will attempt to rebase the changes onto the head of the target train, while keeping the existing revisions in your VCS. When submitting an uplift from a non-unified repo (i.e., `mozilla-central`, `autoland` etc.) no new changesets will be created. You can disable the rebasing behaviour with `--no-rebase`. Once your request has been submitted, navigate to the tip commit of your stack and request an uplift using the action menu, in the same way you accept a revision. ## Reporting Issues We use [Bugzilla](https://bugzilla.mozilla.org/) to track development. File bugs in Bugzilla under [Conduit :: moz-phab](https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=moz-phab). ## Development All python code must be formatted with [black](https://github.com/ambv/black) using the default settings. ### MacOS / Linux 1. Ensure you have Python 3, Git, and Mercurial installed - eg. using `homebrew` on macOS, or your Linux distribution's package manager - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands (adjusting to the version of Python): ```shell `python3 -m venv venv` `source venv/bin/activate` `pip3 install -r dev/requirements/python3.9.txt` `pip3 install -e .` ``` 3. To run moz-phab after making modifications use `moz-phab` 4. To run tests use `pytest -vv` 5. To exit the virtual environment, use `deactivate` ### Windows 1. Install Python 3, Git, and Mercurial: - Run `python3` from the command prompt and install from the Windows store. - Install Git and Mercurial with their respective installers from the official websites. - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands: - `python3 -m venv venv` - `venv\Scripts\pip3 install -r dev-requirements.txt` - `venv\Scripts\pip3 install -e .` 3. To run moz-phab after making modifications use `venv\Scripts\moz-phab` 4. To run tests use `venv\Scripts\pytest -vv` ### Regenerating requirements files Requirements files (those found in the `dev/requirements` directory) are automatically generated using pip-tools. These requirement files are used in the CircleCI configuration to install requirements that run remotely on CircleCI. You can use Docker to regenerate these files. #### On Linux To generate `dev/requirements/python*.*.txt`, run the following commands while in the `dev` directory: - `docker-compose run generate-python3.7-requirements` - `docker-compose run generate-python3.8-requirements` - `docker-compose run generate-python3.9-requirements` - `docker-compose run generate-python3.10-requirements` #### On Windows To generate `dev/requirements/windows.txt`, make sure you are not running Docker in WSL mode then run the following command: - `docker-compose run generate-windows-requirements` ### Circle CI `mozphab` uses Circle CI to ensure all tests pass on macOS, Linux, and Windows. To ensure that your changes work, run `circleci` locally. 1. Ensure you have the `circleci` client installed, see the [CircleCI CLI docs](https://circleci.com/docs/2.0/local-cli/) 2. In your clone of this repository, run: `circleci local execute --job test_3_8` This will run all the Python 3.8 tests in a dockerized environment. This step takes a while, so you might want to run `pytest` for working on your changes, as explained above. #### Circle CI on Windows As of the time of writing, `circleci-cli` on Windows does not allow you to execute Windows tests locally. When CircleCI is running your windows tests remotely, it will use a Windows Orb that is configured to use a special Windows executor that is preloaded with various development packages. The Windows virtual machine will use Miniconda to bootstrap the Python environment, which can cause some problems when installing additional requirements. The `generate-windows` container that is used to generate requirements files for Windows can be used to run your tests, as well as to test package installation. To do that, run the following commands: - `docker-compose run generate-windows powershell.exe` - `cd C:\review` - `pip install dev\requirements\windows.txt` - `pytest` ### Submitting patches Pull Requests are not accepted here; please submit changes to Phabricator using `moz-phab`. 1. Follow the [setup](https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#setting-up-mozphab) 2. Once your patch is written and committed locally, run `moz-phab` to send it to Phabricator. ### Local environment By using [suite](https://github.com/mozilla-conduit/suite), you can run a local environment with its own instances of Phabricator, BMO, Hg, and other services. This enables more thorough integration testing of `moz-phab` without affecting production data. You can order the suite to use your local code by calling: ```shell docker-compose -f docker-compose.yml -f docker-compose.review.yml run local-dev ``` ### Creating Releases To cut a new release of `moz-phab`: 1. Create a tag matching the version number. This will kick off CircleCI jobs to generate the release and push it to PyPI. ```shell git tag -a 1.2.0 origin/main git push origin 1.2.0 ``` 2. Post about the new release in the following channels. Run the `dev/release_announcement.py` script to generate text for the post. - [MozPhab on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog) - [Firefox Tooling Announcements on Discourse](https://discourse.mozilla.org/c/firefox-tooling-announcements) %package -n python3-MozPhab Summary: Phabricator review submission/management tool. Provides: python-MozPhab BuildRequires: python3-devel BuildRequires: python3-setuptools BuildRequires: python3-pip %description -n python3-MozPhab # moz-phab Phabricator CLI from Mozilla to support submission of a series of commits. ## Installation `moz-phab` can be installed with `pip3 install MozPhab`. For detailed installation instructions please see: - [Windows Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-windows.html) - [Linux Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-linux.html) - [macOS Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-macos.html) `moz-phab` will periodically check for updates and seamlessly install the latest release when available. To force update `moz-phab`, run `moz-phab self-update`. ### Changelog Changelog is available on the [MozPhab page on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog). ## Configuration `moz-phab` has an INI style configuration file to control defaults: `~/.moz-phab-config` This file will be created if it doesn't exist. ```ini [ui] no_ansi = False [vcs] safe_mode = False [git] remote = command_path = [hg] command_path = [submit] auto_submit = False always_blocking = False warn_untracked = True [patch] apply_to = base create_bookmark = True create_topic = False always_full_stack = False [updater] self_last_check = 0 self_auto_update = True get_pre_releases = False [error_reporting] report_to_sentry = True ``` - `ui.no_ansi` : Never use ANSI colours (default: auto-detected). - `vcs.safe_mode` : Use only safe VCS settings (default: `False`). Use `--safe-mode` option to switch it on for a one-time usage. - `git.remote`: Comma separated string. Default remotes used to find the first unpublished commit. Default, empty string, means that a list of remotes will be read from `git remote` command. - `git.command_path`: Command path to Git binary. - `hg.command_path`: Command path to Mercurial binary. - `submit.auto_submit` : When `True` the confirmation prompt will be skipped (default: `False`). - `submit.always_blocking` : When `True` reviewers in commit descriptions will be marked as blocking. reviewers specified on the command line override this setting (default: `False`). - `submit.warn_untracked` : When `True` show a warning if there are uncommitted or untracked changes in the working directory (default: `True`). - `patch.apply_to` : [base/here] Where to apply the patches by default. If `"base"` `moz-phab` will look for the SHA1 in the first commit. If `"here"` - current commit/checkout will be used (default: base). - `patch.create_bookmark` : Affects only when patching a Mercurial repository. If `True` moz-phab will create a bookmark (based on the last revision number) for the new DAG branch point. - `patch.create_topic` : Affects only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If `True` moz-phab will create a topic (based on the last revision number) for the new DAG branch point. - `patch.always_full_stack` : When `False` and the patched revision has successors, moz-phab will ask if the whole stack should be patched instead. If `True` moz-phab will do it without without asking. - `updater.self_last_check` : Epoch timestamp (local timezone) indicating the last time an update check was performed for this script. set to `-1` to disable this check. - `self_auto_update` : When `True` moz-phab will auto-update if a new version is available. If `False` moz-phab will only warn about the new version. - `get_pre_releases` : When `True` moz-phab auto-update will fetch pre-releases if they are available, otherwise pre-releases will be ignored (default: `False`). - `error_reporting.report_to_sentry` : When `True` moz-phab will submit exceptions to Sentry so moz-phab devs can see unreported errors. ### Environment Variables `moz-phab` can also be configured via the following environment variables: - `DEBUG` : Enabled debugging output (default: disabled). - `MOZPHAB_NO_USER_CONFIG` : Do not read from or write to `~/.moz-phab-config` (default: disabled). ## Execution To get information about all available commands run ```shell moz-phab -h ``` All commands involving VCS (like `submit` and `patch`) might be used with a `--safe-mode` switch. It will run the VCS command with only chosen set of extensions. ### Submitting commits to Phabricator The simplest invocation is ```shell moz-phab [start_rev] [end_rev] ``` If no positional arguments (`start_rev`/`end_rev`) are given, the range of commits is automatically determined, starting with the first non-public, non-obsolete changeset (for Mercurial) or first unpublished commit (for Git) and ending with the currently checked-out changeset. If at least one argument is given `moz-phab` is following the underlying VCS's `log` behavior. The first argument is interpreted differently in Mercurial (as inclusive) and Git (exclusive). If only one argument is given the end of range is again interpreted as the currently checked-out changeset. If both arguments are given - the second one is interpreted as inclusive. Bug IDs and reviewers are parsed out of commit messages by default. You can set a reviewer as blocking by appending an exclamation mark to the reviewer's nick, e.g. `r=foo!`. If `submit.always_blocking` is set to `true` (see above), reviewers will always be set to blocking regardless. A bug ID can also be set *for every revision in the series* with the `--bug` option, which overrides any bug IDs in commit messages. Similarly, reviewers can be set *for every revision in the series* with `--reviewer` (regular reviewers) and/or `--blocker` (blocking reviewers), which again overrides any reviewers in commit messages. Run `moz-phab submit -h` for more options for submitting revisions. To submit updates to a commit series, run `moz-phab` in the same way with the same arguments, that is, specifying the full original range of commits. Note that, while inserting and amending commits should work fine, reordering commits is not yet supported, and deleting commits will leave the associated revisions open, which should be abandoned manually. See [bug 1481539](https://bugzilla.mozilla.org/show_bug.cgi?id=1481539) for planned fixes. Also note that "fix-up" commits are not yet supported; see [bug 1481542](https://bugzilla.mozilla.org/show_bug.cgi?id=1481542). ### Downloading a patch from Phabricator `moz-phab patch` allows patching an entire stack of revisions. The simplest invocation is ```shell moz-phab patch revision_id ``` To patch a stack ending with the revision `D123` run `moz-phab patch D123`. Diffs will be downloaded from Phabricator and applied using the underlying VCS (`import` for Mercurial or `apply` for Git). A commit for each revision will be created in a new bookmark or topic (Mercurial) or branch (Git). This behavior can be modified with the following options: - `--apply-to TARGET` Define the commit to which apply the patch: - `base` (default) find the base commit in the first ancestor of the revision, - `here` use the current commit, - `{NODE}` use a commit identified by SHA1 or (in Mecurial) revision number - `--raw` Print out the diffs of each revision starting from the oldest ancestor instead of applying to the repository. It can be used to patch the working directory with an external tool: `$ moz-phab patch D123 --raw | patch -p1`. `$ moz-phab patch D123 --raw | hg import`. `$ moz-phab patch D123 --raw | git am`. - `--no-commit` Use the `git apply` command (also for Mercurial repos) to patch the diffs. No commit or branch is created. - `--no-bookmark` : used only when patching a Mercurial repository. If not provided - `moz-phab` will create a bookmark (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-topic` : used only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If not provided and enabled in the configuration - `moz-phab` will create a topic (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-branch`: used only when patching a Git repository. If not provided - `moz-phab` will create a branch (based on the revision number). Otherwise commits will be added just on top of the *base commit* which might result in switching the repository to the 'detached HEAD' state. - `--skip-dependencies` : patch only one revision, ignore dependencies. - `--diff-id DIFF_ID`: used to specify a specific diff within a revision's history to pull. ### Reorganizing the stack `moz-phab reorg [start_rev] [end_rev]` allows you to reorganize the stack in Phabricator. If you've changed the local stack by adding, removing or moving the commits around, you need to change the parent/child relation of the revisions in Phabricator. `moz-phab reorg` command will compare the stack, display what will be changed and ask for permission before taking any action. This behavior can be modified with the following options: - `--no-abandon` Avoid abandoning revisions on Phabricator when they have been removed from the local stack. Only change the dependency relationships between revisions. ### Associating a commit to an existing phabricator revision `moz-phab` tracks which revision is associated with a commit using a line in the commit message. If you want to work on an existing revision from a different machine or environment, we recommend you [apply the existing revision from Phabricator using `moz-phab patch`](#downloading-a-patch-from-phabricator). If that isn't an option for whatever reason, you can associate a new commit to the same revision by adding a line similar to the following to the extended commit message: ```text Differential Revision: https://phabricator.services.mozilla.com/D[revision] ``` replacing `[revision]` with the identifier of your revision. ### Submitting an uplift request `moz-phab uplift` can be used to submit a patch for uplift to a release repository, bypassing the standard release train cycles. See [the Release Management wiki](https://wiki.mozilla.org/Release_Management/Feature_Uplift) for more details about uplifts. To see which trains can be submitted for an uplift request: ```shell moz-phab uplift --list-trains ``` `moz-phab uplift` uses the same syntax as `moz-phab submit`. To submit an uplift request against mozilla-beta: ```shell moz-phab uplift start_rev end_rev --train beta ``` When you submit an uplift within a unified repo (i.e., `mozilla-unified` or `gecko-dev`), `moz-phab uplift` will attempt to rebase the changes onto the head of the target train, while keeping the existing revisions in your VCS. When submitting an uplift from a non-unified repo (i.e., `mozilla-central`, `autoland` etc.) no new changesets will be created. You can disable the rebasing behaviour with `--no-rebase`. Once your request has been submitted, navigate to the tip commit of your stack and request an uplift using the action menu, in the same way you accept a revision. ## Reporting Issues We use [Bugzilla](https://bugzilla.mozilla.org/) to track development. File bugs in Bugzilla under [Conduit :: moz-phab](https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=moz-phab). ## Development All python code must be formatted with [black](https://github.com/ambv/black) using the default settings. ### MacOS / Linux 1. Ensure you have Python 3, Git, and Mercurial installed - eg. using `homebrew` on macOS, or your Linux distribution's package manager - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands (adjusting to the version of Python): ```shell `python3 -m venv venv` `source venv/bin/activate` `pip3 install -r dev/requirements/python3.9.txt` `pip3 install -e .` ``` 3. To run moz-phab after making modifications use `moz-phab` 4. To run tests use `pytest -vv` 5. To exit the virtual environment, use `deactivate` ### Windows 1. Install Python 3, Git, and Mercurial: - Run `python3` from the command prompt and install from the Windows store. - Install Git and Mercurial with their respective installers from the official websites. - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands: - `python3 -m venv venv` - `venv\Scripts\pip3 install -r dev-requirements.txt` - `venv\Scripts\pip3 install -e .` 3. To run moz-phab after making modifications use `venv\Scripts\moz-phab` 4. To run tests use `venv\Scripts\pytest -vv` ### Regenerating requirements files Requirements files (those found in the `dev/requirements` directory) are automatically generated using pip-tools. These requirement files are used in the CircleCI configuration to install requirements that run remotely on CircleCI. You can use Docker to regenerate these files. #### On Linux To generate `dev/requirements/python*.*.txt`, run the following commands while in the `dev` directory: - `docker-compose run generate-python3.7-requirements` - `docker-compose run generate-python3.8-requirements` - `docker-compose run generate-python3.9-requirements` - `docker-compose run generate-python3.10-requirements` #### On Windows To generate `dev/requirements/windows.txt`, make sure you are not running Docker in WSL mode then run the following command: - `docker-compose run generate-windows-requirements` ### Circle CI `mozphab` uses Circle CI to ensure all tests pass on macOS, Linux, and Windows. To ensure that your changes work, run `circleci` locally. 1. Ensure you have the `circleci` client installed, see the [CircleCI CLI docs](https://circleci.com/docs/2.0/local-cli/) 2. In your clone of this repository, run: `circleci local execute --job test_3_8` This will run all the Python 3.8 tests in a dockerized environment. This step takes a while, so you might want to run `pytest` for working on your changes, as explained above. #### Circle CI on Windows As of the time of writing, `circleci-cli` on Windows does not allow you to execute Windows tests locally. When CircleCI is running your windows tests remotely, it will use a Windows Orb that is configured to use a special Windows executor that is preloaded with various development packages. The Windows virtual machine will use Miniconda to bootstrap the Python environment, which can cause some problems when installing additional requirements. The `generate-windows` container that is used to generate requirements files for Windows can be used to run your tests, as well as to test package installation. To do that, run the following commands: - `docker-compose run generate-windows powershell.exe` - `cd C:\review` - `pip install dev\requirements\windows.txt` - `pytest` ### Submitting patches Pull Requests are not accepted here; please submit changes to Phabricator using `moz-phab`. 1. Follow the [setup](https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#setting-up-mozphab) 2. Once your patch is written and committed locally, run `moz-phab` to send it to Phabricator. ### Local environment By using [suite](https://github.com/mozilla-conduit/suite), you can run a local environment with its own instances of Phabricator, BMO, Hg, and other services. This enables more thorough integration testing of `moz-phab` without affecting production data. You can order the suite to use your local code by calling: ```shell docker-compose -f docker-compose.yml -f docker-compose.review.yml run local-dev ``` ### Creating Releases To cut a new release of `moz-phab`: 1. Create a tag matching the version number. This will kick off CircleCI jobs to generate the release and push it to PyPI. ```shell git tag -a 1.2.0 origin/main git push origin 1.2.0 ``` 2. Post about the new release in the following channels. Run the `dev/release_announcement.py` script to generate text for the post. - [MozPhab on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog) - [Firefox Tooling Announcements on Discourse](https://discourse.mozilla.org/c/firefox-tooling-announcements) %package help Summary: Development documents and examples for MozPhab Provides: python3-MozPhab-doc %description help # moz-phab Phabricator CLI from Mozilla to support submission of a series of commits. ## Installation `moz-phab` can be installed with `pip3 install MozPhab`. For detailed installation instructions please see: - [Windows Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-windows.html) - [Linux Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-linux.html) - [macOS Install Instructions](https://moz-conduit.readthedocs.io/en/latest/mozphab-macos.html) `moz-phab` will periodically check for updates and seamlessly install the latest release when available. To force update `moz-phab`, run `moz-phab self-update`. ### Changelog Changelog is available on the [MozPhab page on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog). ## Configuration `moz-phab` has an INI style configuration file to control defaults: `~/.moz-phab-config` This file will be created if it doesn't exist. ```ini [ui] no_ansi = False [vcs] safe_mode = False [git] remote = command_path = [hg] command_path = [submit] auto_submit = False always_blocking = False warn_untracked = True [patch] apply_to = base create_bookmark = True create_topic = False always_full_stack = False [updater] self_last_check = 0 self_auto_update = True get_pre_releases = False [error_reporting] report_to_sentry = True ``` - `ui.no_ansi` : Never use ANSI colours (default: auto-detected). - `vcs.safe_mode` : Use only safe VCS settings (default: `False`). Use `--safe-mode` option to switch it on for a one-time usage. - `git.remote`: Comma separated string. Default remotes used to find the first unpublished commit. Default, empty string, means that a list of remotes will be read from `git remote` command. - `git.command_path`: Command path to Git binary. - `hg.command_path`: Command path to Mercurial binary. - `submit.auto_submit` : When `True` the confirmation prompt will be skipped (default: `False`). - `submit.always_blocking` : When `True` reviewers in commit descriptions will be marked as blocking. reviewers specified on the command line override this setting (default: `False`). - `submit.warn_untracked` : When `True` show a warning if there are uncommitted or untracked changes in the working directory (default: `True`). - `patch.apply_to` : [base/here] Where to apply the patches by default. If `"base"` `moz-phab` will look for the SHA1 in the first commit. If `"here"` - current commit/checkout will be used (default: base). - `patch.create_bookmark` : Affects only when patching a Mercurial repository. If `True` moz-phab will create a bookmark (based on the last revision number) for the new DAG branch point. - `patch.create_topic` : Affects only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If `True` moz-phab will create a topic (based on the last revision number) for the new DAG branch point. - `patch.always_full_stack` : When `False` and the patched revision has successors, moz-phab will ask if the whole stack should be patched instead. If `True` moz-phab will do it without without asking. - `updater.self_last_check` : Epoch timestamp (local timezone) indicating the last time an update check was performed for this script. set to `-1` to disable this check. - `self_auto_update` : When `True` moz-phab will auto-update if a new version is available. If `False` moz-phab will only warn about the new version. - `get_pre_releases` : When `True` moz-phab auto-update will fetch pre-releases if they are available, otherwise pre-releases will be ignored (default: `False`). - `error_reporting.report_to_sentry` : When `True` moz-phab will submit exceptions to Sentry so moz-phab devs can see unreported errors. ### Environment Variables `moz-phab` can also be configured via the following environment variables: - `DEBUG` : Enabled debugging output (default: disabled). - `MOZPHAB_NO_USER_CONFIG` : Do not read from or write to `~/.moz-phab-config` (default: disabled). ## Execution To get information about all available commands run ```shell moz-phab -h ``` All commands involving VCS (like `submit` and `patch`) might be used with a `--safe-mode` switch. It will run the VCS command with only chosen set of extensions. ### Submitting commits to Phabricator The simplest invocation is ```shell moz-phab [start_rev] [end_rev] ``` If no positional arguments (`start_rev`/`end_rev`) are given, the range of commits is automatically determined, starting with the first non-public, non-obsolete changeset (for Mercurial) or first unpublished commit (for Git) and ending with the currently checked-out changeset. If at least one argument is given `moz-phab` is following the underlying VCS's `log` behavior. The first argument is interpreted differently in Mercurial (as inclusive) and Git (exclusive). If only one argument is given the end of range is again interpreted as the currently checked-out changeset. If both arguments are given - the second one is interpreted as inclusive. Bug IDs and reviewers are parsed out of commit messages by default. You can set a reviewer as blocking by appending an exclamation mark to the reviewer's nick, e.g. `r=foo!`. If `submit.always_blocking` is set to `true` (see above), reviewers will always be set to blocking regardless. A bug ID can also be set *for every revision in the series* with the `--bug` option, which overrides any bug IDs in commit messages. Similarly, reviewers can be set *for every revision in the series* with `--reviewer` (regular reviewers) and/or `--blocker` (blocking reviewers), which again overrides any reviewers in commit messages. Run `moz-phab submit -h` for more options for submitting revisions. To submit updates to a commit series, run `moz-phab` in the same way with the same arguments, that is, specifying the full original range of commits. Note that, while inserting and amending commits should work fine, reordering commits is not yet supported, and deleting commits will leave the associated revisions open, which should be abandoned manually. See [bug 1481539](https://bugzilla.mozilla.org/show_bug.cgi?id=1481539) for planned fixes. Also note that "fix-up" commits are not yet supported; see [bug 1481542](https://bugzilla.mozilla.org/show_bug.cgi?id=1481542). ### Downloading a patch from Phabricator `moz-phab patch` allows patching an entire stack of revisions. The simplest invocation is ```shell moz-phab patch revision_id ``` To patch a stack ending with the revision `D123` run `moz-phab patch D123`. Diffs will be downloaded from Phabricator and applied using the underlying VCS (`import` for Mercurial or `apply` for Git). A commit for each revision will be created in a new bookmark or topic (Mercurial) or branch (Git). This behavior can be modified with the following options: - `--apply-to TARGET` Define the commit to which apply the patch: - `base` (default) find the base commit in the first ancestor of the revision, - `here` use the current commit, - `{NODE}` use a commit identified by SHA1 or (in Mecurial) revision number - `--raw` Print out the diffs of each revision starting from the oldest ancestor instead of applying to the repository. It can be used to patch the working directory with an external tool: `$ moz-phab patch D123 --raw | patch -p1`. `$ moz-phab patch D123 --raw | hg import`. `$ moz-phab patch D123 --raw | git am`. - `--no-commit` Use the `git apply` command (also for Mercurial repos) to patch the diffs. No commit or branch is created. - `--no-bookmark` : used only when patching a Mercurial repository. If not provided - `moz-phab` will create a bookmark (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-topic` : used only when patching a Mercurial repository. Requires the `topic` extension to be enabled. If not provided and enabled in the configuration - `moz-phab` will create a topic (based on the last revision number) for the new DAG branch point. The default behavior [is configurable](#configuration). - `--no-branch`: used only when patching a Git repository. If not provided - `moz-phab` will create a branch (based on the revision number). Otherwise commits will be added just on top of the *base commit* which might result in switching the repository to the 'detached HEAD' state. - `--skip-dependencies` : patch only one revision, ignore dependencies. - `--diff-id DIFF_ID`: used to specify a specific diff within a revision's history to pull. ### Reorganizing the stack `moz-phab reorg [start_rev] [end_rev]` allows you to reorganize the stack in Phabricator. If you've changed the local stack by adding, removing or moving the commits around, you need to change the parent/child relation of the revisions in Phabricator. `moz-phab reorg` command will compare the stack, display what will be changed and ask for permission before taking any action. This behavior can be modified with the following options: - `--no-abandon` Avoid abandoning revisions on Phabricator when they have been removed from the local stack. Only change the dependency relationships between revisions. ### Associating a commit to an existing phabricator revision `moz-phab` tracks which revision is associated with a commit using a line in the commit message. If you want to work on an existing revision from a different machine or environment, we recommend you [apply the existing revision from Phabricator using `moz-phab patch`](#downloading-a-patch-from-phabricator). If that isn't an option for whatever reason, you can associate a new commit to the same revision by adding a line similar to the following to the extended commit message: ```text Differential Revision: https://phabricator.services.mozilla.com/D[revision] ``` replacing `[revision]` with the identifier of your revision. ### Submitting an uplift request `moz-phab uplift` can be used to submit a patch for uplift to a release repository, bypassing the standard release train cycles. See [the Release Management wiki](https://wiki.mozilla.org/Release_Management/Feature_Uplift) for more details about uplifts. To see which trains can be submitted for an uplift request: ```shell moz-phab uplift --list-trains ``` `moz-phab uplift` uses the same syntax as `moz-phab submit`. To submit an uplift request against mozilla-beta: ```shell moz-phab uplift start_rev end_rev --train beta ``` When you submit an uplift within a unified repo (i.e., `mozilla-unified` or `gecko-dev`), `moz-phab uplift` will attempt to rebase the changes onto the head of the target train, while keeping the existing revisions in your VCS. When submitting an uplift from a non-unified repo (i.e., `mozilla-central`, `autoland` etc.) no new changesets will be created. You can disable the rebasing behaviour with `--no-rebase`. Once your request has been submitted, navigate to the tip commit of your stack and request an uplift using the action menu, in the same way you accept a revision. ## Reporting Issues We use [Bugzilla](https://bugzilla.mozilla.org/) to track development. File bugs in Bugzilla under [Conduit :: moz-phab](https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit&component=moz-phab). ## Development All python code must be formatted with [black](https://github.com/ambv/black) using the default settings. ### MacOS / Linux 1. Ensure you have Python 3, Git, and Mercurial installed - eg. using `homebrew` on macOS, or your Linux distribution's package manager - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands (adjusting to the version of Python): ```shell `python3 -m venv venv` `source venv/bin/activate` `pip3 install -r dev/requirements/python3.9.txt` `pip3 install -e .` ``` 3. To run moz-phab after making modifications use `moz-phab` 4. To run tests use `pytest -vv` 5. To exit the virtual environment, use `deactivate` ### Windows 1. Install Python 3, Git, and Mercurial: - Run `python3` from the command prompt and install from the Windows store. - Install Git and Mercurial with their respective installers from the official websites. - `python3`, `git`, and `hg` executables must be on the system path 2. In your clone of this repository run the following commands: - `python3 -m venv venv` - `venv\Scripts\pip3 install -r dev-requirements.txt` - `venv\Scripts\pip3 install -e .` 3. To run moz-phab after making modifications use `venv\Scripts\moz-phab` 4. To run tests use `venv\Scripts\pytest -vv` ### Regenerating requirements files Requirements files (those found in the `dev/requirements` directory) are automatically generated using pip-tools. These requirement files are used in the CircleCI configuration to install requirements that run remotely on CircleCI. You can use Docker to regenerate these files. #### On Linux To generate `dev/requirements/python*.*.txt`, run the following commands while in the `dev` directory: - `docker-compose run generate-python3.7-requirements` - `docker-compose run generate-python3.8-requirements` - `docker-compose run generate-python3.9-requirements` - `docker-compose run generate-python3.10-requirements` #### On Windows To generate `dev/requirements/windows.txt`, make sure you are not running Docker in WSL mode then run the following command: - `docker-compose run generate-windows-requirements` ### Circle CI `mozphab` uses Circle CI to ensure all tests pass on macOS, Linux, and Windows. To ensure that your changes work, run `circleci` locally. 1. Ensure you have the `circleci` client installed, see the [CircleCI CLI docs](https://circleci.com/docs/2.0/local-cli/) 2. In your clone of this repository, run: `circleci local execute --job test_3_8` This will run all the Python 3.8 tests in a dockerized environment. This step takes a while, so you might want to run `pytest` for working on your changes, as explained above. #### Circle CI on Windows As of the time of writing, `circleci-cli` on Windows does not allow you to execute Windows tests locally. When CircleCI is running your windows tests remotely, it will use a Windows Orb that is configured to use a special Windows executor that is preloaded with various development packages. The Windows virtual machine will use Miniconda to bootstrap the Python environment, which can cause some problems when installing additional requirements. The `generate-windows` container that is used to generate requirements files for Windows can be used to run your tests, as well as to test package installation. To do that, run the following commands: - `docker-compose run generate-windows powershell.exe` - `cd C:\review` - `pip install dev\requirements\windows.txt` - `pytest` ### Submitting patches Pull Requests are not accepted here; please submit changes to Phabricator using `moz-phab`. 1. Follow the [setup](https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#setting-up-mozphab) 2. Once your patch is written and committed locally, run `moz-phab` to send it to Phabricator. ### Local environment By using [suite](https://github.com/mozilla-conduit/suite), you can run a local environment with its own instances of Phabricator, BMO, Hg, and other services. This enables more thorough integration testing of `moz-phab` without affecting production data. You can order the suite to use your local code by calling: ```shell docker-compose -f docker-compose.yml -f docker-compose.review.yml run local-dev ``` ### Creating Releases To cut a new release of `moz-phab`: 1. Create a tag matching the version number. This will kick off CircleCI jobs to generate the release and push it to PyPI. ```shell git tag -a 1.2.0 origin/main git push origin 1.2.0 ``` 2. Post about the new release in the following channels. Run the `dev/release_announcement.py` script to generate text for the post. - [MozPhab on Mozilla Wiki](https://wiki.mozilla.org/MozPhab/Changelog) - [Firefox Tooling Announcements on Discourse](https://discourse.mozilla.org/c/firefox-tooling-announcements) %prep %autosetup -n MozPhab-1.4.3 %build %py3_build %install %py3_install install -d -m755 %{buildroot}/%{_pkgdocdir} if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi pushd %{buildroot} if [ -d usr/lib ]; then find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/lib64 ]; then find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/bin ]; then find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst fi if [ -d usr/sbin ]; then find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst fi touch doclist.lst if [ -d usr/share/man ]; then find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst fi popd mv %{buildroot}/filelist.lst . mv %{buildroot}/doclist.lst . %files -n python3-MozPhab -f filelist.lst %dir %{python3_sitelib}/* %files help -f doclist.lst %{_docdir}/* %changelog * Wed May 10 2023 Python_Bot - 1.4.3-1 - Package Spec generated