зеркало из https://github.com/mozilla/bedrock.git
Родитель
9611d996da
Коммит
a66ee5fa2b
|
@ -16,19 +16,38 @@ JavaScript and CSS.
|
|||
Git workflow
|
||||
------------
|
||||
When you want to start contributing, you should create a branch from master.
|
||||
This allows you to work on different project at the same time::
|
||||
This allows you to work on different project at the same time:
|
||||
|
||||
git checkout master
|
||||
git checkout -b topic-branch
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout master
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout -b topic-branch
|
||||
|
||||
To keep your branch up-to-date, assuming the mozilla repository is the remote
|
||||
called mozilla::
|
||||
called mozilla:
|
||||
|
||||
git fetch mozilla
|
||||
git checkout master
|
||||
git merge mozilla/master
|
||||
git checkout topic-branch
|
||||
git rebase master
|
||||
.. code-block:: bash
|
||||
|
||||
$ git fetch mozilla
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout master
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git merge mozilla/master
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git checkout topic-branch
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git rebase master
|
||||
|
||||
If you need more Git expertise, a good resource is the `Git book`_.
|
||||
|
||||
|
@ -51,9 +70,13 @@ If you're asked to change your commit message, you can use these commands:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
git commit --amend
|
||||
# -f is doing a force push because you modified the history
|
||||
git push -f my-remote topic-branch
|
||||
$ git commit --amend
|
||||
|
||||
-f is doing a force push because you modified the history
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git push -f my-remote topic-branch
|
||||
|
||||
Submitting your work
|
||||
--------------------
|
||||
|
@ -72,9 +95,9 @@ Should your pull request contain more than one commit, sometimes we may ask you
|
|||
to squash them into a single commit before merging. You can do this with `git rebase`.
|
||||
|
||||
As an example, let's say your pull request contains two commits. To squash them
|
||||
into a single commit, you can follow these instructions:
|
||||
into a single commit, you can follow these instructions::
|
||||
|
||||
git rebase -i HEAD~2
|
||||
$ git rebase -i HEAD~2
|
||||
|
||||
You will then get an editor with your two commits listed. Change the second
|
||||
commit from `pick` to `fixup`, then save and close. You should then be able to
|
||||
|
@ -143,9 +166,9 @@ the bugs that have been pushed with a quick message stating that the code was de
|
|||
If you'd like to see the commits that will be deployed before the push run the
|
||||
following command:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: bash
|
||||
|
||||
./bin/open-compare.py
|
||||
$ ./bin/open-compare.py
|
||||
|
||||
This will discover the currently deployed git hash, and open a compare URL at github
|
||||
to the latest master. Look at ``open-compare.py -h`` for more options.
|
||||
|
|
|
@ -31,6 +31,9 @@ The first step is to create the recipe. Let's say you want to convert
|
|||
.. code-block:: bash
|
||||
|
||||
$ make run-shell
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py fluent recipe bedrock/mozorg/templates/mozorg/mission.html
|
||||
|
||||
This will parse all of the calls to ``_()`` and the ``trans`` blocks, process the strings in the
|
||||
|
@ -86,6 +89,9 @@ continue with the example of ``mission.html``; you would run:
|
|||
.. code-block:: bash
|
||||
|
||||
$ make run-shell
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py fluent ftl bedrock/mozorg/templates/mozorg/mission.html
|
||||
|
||||
This should create ``l10n/en/mozorg/mission.ftl`` which has all of the strings
|
||||
|
@ -100,6 +106,9 @@ it for errors like duplicated IDs.
|
|||
.. code-block:: bash
|
||||
|
||||
$ moz-l10n-lint l10n/l10n-pontoon.toml
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ moz-l10n-lint l10n/l10n-vendor.toml
|
||||
|
||||
Convert the template
|
||||
|
@ -154,6 +163,9 @@ files in our fluent files repo.
|
|||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py fluent ftl bedrock/mozorg/templates/mozorg/mission.html de it
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py fluent ftl lib/fluent_migrations/mozorg/mission.py de it
|
||||
|
||||
This is the same command we used to create the original ``en`` Fluent file.
|
||||
|
|
|
@ -11,9 +11,14 @@ Installing Bedrock
|
|||
Installation Methods
|
||||
====================
|
||||
|
||||
There are two primary methods of installing bedrock: Docker and Local. Whichever you choose you'll start by getting the source::
|
||||
There are two primary methods of installing bedrock: Docker and Local. Whichever you choose you'll start by getting the source
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone git://github.com/mozilla/bedrock.git
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cd bedrock
|
||||
|
||||
After these basic steps you can choose your install method below. Docker is the easiest and recommended way, but local is also possible
|
||||
|
@ -49,12 +54,19 @@ choice and modify things and you should see those changes reflected in your brow
|
|||
ensuring that you have the latest dependencies installed among other things. If you see any strange errors after a
|
||||
``git pull`` then ``make pull`` is a good thing to try for a quick fix.
|
||||
|
||||
If you don't have or want to use Make you can call the docker and compose commands directly::
|
||||
If you don't have or want to use Make you can call the docker and compose commands directly
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ docker-compose pull
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ [[ ! -f .env ]] && cp .env-dist .env
|
||||
|
||||
Then starting it all is simply::
|
||||
Then starting it all is simply
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ docker-compose up app assets
|
||||
|
||||
|
@ -85,16 +97,33 @@ Local Installation
|
|||
These instructions assume you have Python 3.6+, pip, and NodeJS installed. If you don't have `pip` installed
|
||||
(you probably do) you can install it with the instructions in `the pip docs <https://pip.pypa.io/en/stable/installing/>`_.
|
||||
|
||||
You need to create a virtual environment for Python libraries::
|
||||
You need to create a virtual environment for Python libraries:
|
||||
|
||||
$ python3 -m venv venv # create a virtual env in the folder `venv`
|
||||
$ source venv/bin/activate # activate the virtual env. On Windows, run: venv\Scripts\activate.bat
|
||||
$ pip install --upgrade pip # securely upgrade pip
|
||||
$ pip install -r requirements/dev.txt # installs dependencies
|
||||
1. Create a virtual env in the folder `venv` ::
|
||||
|
||||
If you are on OSX and some of the compiled dependencies fails to compile, try explicitly setting the arch flags and try again::
|
||||
$ python3 -m venv venv
|
||||
|
||||
2. Activate the virtual env. On Windows, run: venv\Scripts\activate.bat ::
|
||||
|
||||
$ source venv/bin/activate
|
||||
|
||||
3. Securely upgrade pip ::
|
||||
|
||||
$ pip install --upgrade pip
|
||||
|
||||
4. Installs dependencies ::
|
||||
|
||||
$ pip install -r requirements/dev.txt
|
||||
|
||||
|
||||
If you are on OSX and some of the compiled dependencies fails to compile, try explicitly setting the arch flags and try again
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ export ARCHFLAGS="-arch i386 -arch x86_64"
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install -r requirements/dev.txt
|
||||
|
||||
If you are on Linux, you will need at least the following packages or their equivalent for your distro::
|
||||
|
@ -251,6 +280,9 @@ Local:
|
|||
.. code-block:: bash
|
||||
|
||||
$ pip install -r requirements/docs.txt
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ make livedocs
|
||||
|
||||
|
||||
|
|
|
@ -526,7 +526,14 @@ if you'd like something a bit nicer looking and more convenient there is the
|
|||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py l10n_update
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./manage.py active_locales mozorg/mission
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
There are 91 active locales for mozorg/mission.ftl:
|
||||
- af
|
||||
- an
|
||||
|
@ -840,6 +847,9 @@ You can specify a list of locales to update:
|
|||
.. code-block:: console
|
||||
|
||||
$ ./manage.py l10n_check fr
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./manage.py l10n_check fr de es
|
||||
|
||||
Currency
|
||||
|
|
|
@ -89,9 +89,14 @@ to change according to the settings in the `.gitlab-ci.yml file in the www-confi
|
|||
By default the ``tag-release.sh`` script will push to the ``origin`` git remote. If you'd
|
||||
like for it to push to a different remote name you can either pass in a ``-r`` or
|
||||
``--remote`` argument, or set the ``MOZ_GIT_REMOTE`` environment variable. So the following
|
||||
are equivalent::
|
||||
are equivalent:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ bin/tag-release.sh --push -r mozilla
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ MOZ_GIT_REMOTE=mozilla bin/tag-release.sh --push
|
||||
|
||||
And if you'd like to just tag and not push the tag anywhere, you may omit the ``--push``
|
||||
|
|
|
@ -166,6 +166,9 @@ following commands:
|
|||
.. code-block:: bash
|
||||
|
||||
$ source venv/bin/activate
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install -r requirements/dev.txt
|
||||
|
||||
Running the tests
|
||||
|
|
|
@ -31,6 +31,9 @@ installed by using the following commands:
|
|||
.. code-block:: bash
|
||||
|
||||
$ source venv/bin/activate
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ pip install -r requirements/dev.txt
|
||||
|
||||
Running Jasmine tests using Karma
|
||||
|
|
Загрузка…
Ссылка в новой задаче