mirror of
https://github.com/django/django.git
synced 2025-11-02 04:48:33 +00:00
Fixed #24358 -- Corrected code-block directives for console sessions.
This commit is contained in:
Sean Wang
Tim Graham
parent
ea3168dc6c
commit
eba6dff581
17 changed files with 100 additions and 134 deletions
|
|
@ -48,7 +48,7 @@ Imports
|
|||
|
||||
Quick start:
|
||||
|
||||
.. code-block:: bash
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install isort
|
||||
$ isort -rc .
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
Unit tests
|
||||
==========
|
||||
|
||||
.. highlight:: console
|
||||
|
||||
Django comes with a test suite of its own, in the ``tests`` directory of the
|
||||
code base. It's our policy to make sure all tests pass at all times.
|
||||
|
||||
|
|
@ -26,9 +28,7 @@ the other optional test dependencies.
|
|||
|
||||
Running the tests requires a Django settings module that defines the
|
||||
databases to use. To make it easy to get started, Django provides and uses a
|
||||
sample settings module that uses the SQLite database. To run the tests:
|
||||
|
||||
.. code-block:: bash
|
||||
sample settings module that uses the SQLite database. To run the tests::
|
||||
|
||||
$ git clone https://github.com/django/django.git django-repo
|
||||
$ cd django-repo/tests
|
||||
|
|
@ -96,9 +96,7 @@ tests by appending the names of the test modules to ``runtests.py`` on the
|
|||
command line.
|
||||
|
||||
For example, if you'd like to run tests only for generic relations and
|
||||
internationalization, type:
|
||||
|
||||
.. code-block:: bash
|
||||
internationalization, type::
|
||||
|
||||
$ ./runtests.py --settings=path.to.settings generic_relations i18n
|
||||
|
||||
|
|
@ -107,15 +105,11 @@ directory name there is the name of a test.
|
|||
|
||||
If you just want to run a particular class of tests, you can specify a list of
|
||||
paths to individual test classes. For example, to run the ``TranslationTests``
|
||||
of the ``i18n`` module, type:
|
||||
|
||||
.. code-block:: bash
|
||||
of the ``i18n`` module, type::
|
||||
|
||||
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests
|
||||
|
||||
Going beyond that, you can specify an individual test method like this:
|
||||
|
||||
.. code-block:: bash
|
||||
Going beyond that, you can specify an individual test method like this::
|
||||
|
||||
$ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
|
||||
|
||||
|
|
@ -125,9 +119,7 @@ Running the Selenium tests
|
|||
Some tests require Selenium and a Web browser (Firefox, Google Chrome, or
|
||||
Internet Explorer). To allow those tests to be run rather than skipped, you must
|
||||
install the selenium_ package into your Python path and run the tests with the
|
||||
``--selenium`` option:
|
||||
|
||||
.. code-block:: bash
|
||||
``--selenium`` option::
|
||||
|
||||
$ ./runtests.py --settings=test_sqlite --selenium admin_inlines
|
||||
|
||||
|
|
@ -154,9 +146,7 @@ dependencies:
|
|||
|
||||
You can find these dependencies in `pip requirements files`_ inside the
|
||||
``tests/requirements`` directory of the Django source tree and install them
|
||||
like so:
|
||||
|
||||
.. code-block:: bash
|
||||
like so::
|
||||
|
||||
$ pip install -r tests/requirements/py3.txt # Python 2: py2.txt
|
||||
|
||||
|
|
@ -193,15 +183,11 @@ Contributors are encouraged to run coverage on the test suite to identify areas
|
|||
that need additional tests. The coverage tool installation and use is described
|
||||
in :ref:`testing code coverage<topics-testing-code-coverage>`.
|
||||
|
||||
To run coverage on the Django test suite using the standard test settings:
|
||||
|
||||
.. code-block:: bash
|
||||
To run coverage on the Django test suite using the standard test settings::
|
||||
|
||||
$ coverage run ./runtests.py --settings=test_sqlite
|
||||
|
||||
After running coverage, generate the html report by running:
|
||||
|
||||
.. code-block:: bash
|
||||
After running coverage, generate the html report by running::
|
||||
|
||||
$ coverage html
|
||||
|
||||
|
|
@ -230,9 +216,7 @@ Many test failures with ``UnicodeEncodeError``
|
|||
If the ``locales`` package is not installed, some tests will fail with a
|
||||
``UnicodeEncodeError``.
|
||||
|
||||
You can resolve this on Debian-based systems, for example, by running:
|
||||
|
||||
.. code-block:: bash
|
||||
You can resolve this on Debian-based systems, for example, by running::
|
||||
|
||||
$ apt-get install locales
|
||||
$ dpkg-reconfigure locales
|
||||
|
|
@ -249,9 +233,7 @@ it possible to identify a small number of tests that may be related to the
|
|||
failure.
|
||||
|
||||
For example, suppose that the failing test that works on its own is
|
||||
``ModelTest.test_eq``, then using:
|
||||
|
||||
.. code-block:: bash
|
||||
``ModelTest.test_eq``, then using::
|
||||
|
||||
$ ./runtests.py --bisect basic.tests.ModelTest.test_eq
|
||||
|
||||
|
|
@ -265,9 +247,7 @@ failing tests is minimized.
|
|||
|
||||
The ``--pair`` option runs the given test alongside every other test from the
|
||||
suite, letting you check if another test has side-effects that cause the
|
||||
failure. So:
|
||||
|
||||
.. code-block:: bash
|
||||
failure. So::
|
||||
|
||||
$ ./runtests.py --pair basic.tests.ModelTest.test_eq
|
||||
|
||||
|
|
@ -276,25 +256,19 @@ will pair ``test_eq`` with every test label.
|
|||
With both ``--bisect`` and ``--pair``, if you already suspect which cases
|
||||
might be responsible for the failure, you may limit tests to be cross-analyzed
|
||||
by :ref:`specifying further test labels <runtests-specifying-labels>` after
|
||||
the first one:
|
||||
|
||||
.. code-block:: bash
|
||||
the first one::
|
||||
|
||||
$ ./runtests.py --pair basic.tests.ModelTest.test_eq queries transactions
|
||||
|
||||
You can also try running any set of tests in reverse using the ``--reverse``
|
||||
option in order to verify that executing tests in a different order does not
|
||||
cause any trouble:
|
||||
|
||||
.. code-block:: bash
|
||||
cause any trouble::
|
||||
|
||||
$ ./runtests.py basic --reverse
|
||||
|
||||
If you wish to examine the SQL being run in failing tests, you can turn on
|
||||
:ref:`SQL logging <django-db-logger>` using the ``--debug-sql`` option. If you
|
||||
combine this with ``--verbosity=2``, all SQL queries will be output.
|
||||
|
||||
.. code-block:: bash
|
||||
combine this with ``--verbosity=2``, all SQL queries will be output::
|
||||
|
||||
$ ./runtests.py basic --debug-sql
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
How is Django Formed?
|
||||
=====================
|
||||
|
||||
.. highlight:: console
|
||||
|
||||
This document explains how to release Django.
|
||||
|
||||
**Please, keep these instructions up-to-date if you make changes!** The point
|
||||
|
|
@ -54,9 +56,7 @@ You'll need a few things before getting started:
|
|||
``you@example.com`` is the email address associated with the key you want to
|
||||
use.
|
||||
|
||||
* An install of some required Python packages:
|
||||
|
||||
.. code-block:: bash
|
||||
* An install of some required Python packages::
|
||||
|
||||
$ pip install wheel twine
|
||||
|
||||
|
|
@ -117,7 +117,7 @@ any time leading up to the actual release:
|
|||
rather than the releaser, but here are the steps. Provided you have an
|
||||
account on Transifex::
|
||||
|
||||
python scripts/manage_translations.py fetch
|
||||
$ python scripts/manage_translations.py fetch
|
||||
|
||||
and then commit the changed/added files (both .po and .mo). Sometimes there
|
||||
are validation errors which need to be debugged, so avoid doing this task
|
||||
|
|
@ -148,16 +148,16 @@ OK, this is the fun part, where we actually push out a release!
|
|||
#. A release always begins from a release branch, so you should make sure
|
||||
you're on a stable branch and up-to-date. For example::
|
||||
|
||||
git checkout stable/1.5.x
|
||||
git pull
|
||||
$ git checkout stable/1.5.x
|
||||
$ git pull
|
||||
|
||||
#. If this is a security release, merge the appropriate patches from
|
||||
``django-private``. Rebase these patches as necessary to make each one a
|
||||
simple commit on the release branch rather than a merge commit. To ensure
|
||||
this, merge them with the ``--ff-only`` flag; for example::
|
||||
|
||||
git checkout stable/1.5.x
|
||||
git merge --ff-only security/1.5.x
|
||||
$ git checkout stable/1.5.x
|
||||
$ git merge --ff-only security/1.5.x
|
||||
|
||||
(This assumes ``security/1.5.x`` is a branch in the ``django-private`` repo
|
||||
containing the necessary security patches for the next release in the 1.5
|
||||
|
|
@ -193,7 +193,7 @@ OK, this is the fun part, where we actually push out a release!
|
|||
|
||||
#. Tag the release using ``git tag``. For example::
|
||||
|
||||
git tag --sign --message="Tag 1.5.1" 1.5.1
|
||||
$ git tag --sign --message="Tag 1.5.1" 1.5.1
|
||||
|
||||
You can check your work by running ``git tag --verify <tag>``.
|
||||
|
||||
|
|
@ -205,9 +205,7 @@ OK, this is the fun part, where we actually push out a release!
|
|||
create the release packages in a ``dist/`` directory. Note that we don't
|
||||
publish wheel files for 1.4.
|
||||
|
||||
#. Generate the hashes of the release packages:
|
||||
|
||||
.. code-block:: bash
|
||||
#. Generate the hashes of the release packages::
|
||||
|
||||
$ cd dist
|
||||
$ md5sum *
|
||||
|
|
@ -217,7 +215,9 @@ OK, this is the fun part, where we actually push out a release!
|
|||
#. Create a "checksums" file, ``Django-<<VERSION>>.checksum.txt`` containing
|
||||
the hashes and release information. Start with this template and insert the
|
||||
correct version, date, GPG key ID (from
|
||||
``gpg --list-keys --keyid-format LONG``), release URL, and checksums::
|
||||
``gpg --list-keys --keyid-format LONG``), release URL, and checksums:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
This file contains MD5, SHA1, and SHA256 checksums for the source-code
|
||||
tarball of Django <<VERSION>>, released <<DATE>>.
|
||||
|
|
@ -276,22 +276,16 @@ Making the release(s) available to the public
|
|||
Now you're ready to actually put the release out there. To do this:
|
||||
|
||||
#. Upload the release package(s) to the djangoproject server, replacing
|
||||
A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release:
|
||||
|
||||
.. code-block:: bash
|
||||
A.B. with the appropriate version number, e.g. 1.5 for a 1.5.x release::
|
||||
|
||||
$ scp Django-* djangoproject.com:/home/www/www/media/releases/A.B
|
||||
|
||||
#. Upload the checksum file(s):
|
||||
|
||||
.. code-block:: bash
|
||||
#. Upload the checksum file(s)::
|
||||
|
||||
$ scp Django-A.B.C.checksum.txt.asc djangoproject.com:/home/www/www/media/pgp/Django-A.B.C.checksum.txt
|
||||
|
||||
#. Test that the release packages install correctly using ``easy_install``
|
||||
and ``pip``. Here's one method (which requires `virtualenvwrapper`__):
|
||||
|
||||
.. code-block:: bash
|
||||
and ``pip``. Here's one method (which requires `virtualenvwrapper`__)::
|
||||
|
||||
$ RELEASE_VERSION='1.7.2'
|
||||
$ MAJOR_VERSION=`echo $RELEASE_VERSION| cut -c 1-3`
|
||||
|
|
@ -318,9 +312,7 @@ Now you're ready to actually put the release out there. To do this:
|
|||
correct (proper version numbers, no stray ``.pyc`` or other undesirable
|
||||
files).
|
||||
|
||||
#. Upload the release packages to PyPI:
|
||||
|
||||
.. code-block:: bash
|
||||
#. Upload the release packages to PyPI::
|
||||
|
||||
$ twine upload -s dist/*
|
||||
|
||||
|
|
@ -334,7 +326,7 @@ Now you're ready to actually put the release out there. To do this:
|
|||
#. Make the blog post announcing the release live.
|
||||
|
||||
#. For a new version release (e.g. 1.5, 1.6), update the default stable version
|
||||
of the docs by flipping the ``is_default`` flag to ``True`` on the
|
||||
of the docs by flipping the ``is_default`` flag to `deployment/wsgi/uwsgi.html`True`` on the
|
||||
appropriate ``DocumentRelease`` object in the ``docs.djangoproject.com``
|
||||
database (this will automatically flip it to ``False`` for all
|
||||
others); you can do this using the site's admin.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue