docs: small rst fixes.

docs/admin/nginx-config-example.rst

@@ -1,134 +1,135 b''
 Nginx Configuration Example
 ---------------------------
 
 Use the following example to configure Nginx as a your web server.
 
 
 .. code-block:: nginx
+
     ## rate limiter for certain pages to prevent brute force attacks
     limit_req_zone  $binary_remote_addr  zone=dl_limit:10m   rate=1r/s;
 
     ## custom log format
     log_format log_custom '$remote_addr - $remote_user [$time_local] '
                           '"$request" $status $body_bytes_sent '
                           '"$http_referer" "$http_user_agent" '
                           '$request_time $upstream_response_time $pipe';
 
     ## define upstream (local RhodeCode instance) to connect to
     upstream rc {
         # Url to running RhodeCode instance.
         # This is shown as `- URL:` in output from rccontrol status.
         server 127.0.0.1:10002;
 
         # add more instances for load balancing
         # server 127.0.0.1:10003;
         # server 127.0.0.1:10004;
     }
 
     ## HTTP to HTTPS rewrite
     server {
         listen          80;
         server_name     rhodecode.myserver.com;
 
         if ($http_host = rhodecode.myserver.com) {
             rewrite  (.*)  https://rhodecode.myserver.com$1 permanent;
         }
     }
 
     ## Optional gist alias server, for serving nicer GIST urls.
     server {
         listen          443;
         server_name     gist.myserver.com;
         access_log      /var/log/nginx/gist.access.log log_custom;
         error_log       /var/log/nginx/gist.error.log;
 
         ssl on;
         ssl_certificate     gist.rhodecode.myserver.com.crt;
         ssl_certificate_key gist.rhodecode.myserver.com.key;
 
         ssl_session_timeout 5m;
 
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         ssl_prefer_server_ciphers on;
         ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 
         # strict http prevents from https -> http downgrade
         add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
 
         # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
         #ssl_dhparam /etc/nginx/ssl/dhparam.pem;
 
         rewrite ^/(.+)$ https://rhodecode.myserver.com/_admin/gists/$1;
         rewrite (.*)    https://rhodecode.myserver.com/_admin/gists;
     }
 
 
     ## MAIN SSL enabled server
     server {
         listen       443 ssl;
         server_name  rhodecode.myserver.com;
 
         access_log   /var/log/nginx/rhodecode.access.log log_custom;
         error_log    /var/log/nginx/rhodecode.error.log;
 
         ssl on;
         ssl_certificate     rhodecode.myserver.com.crt;
         ssl_certificate_key rhodecode.myserver.com.key;
 
         ssl_session_timeout 5m;
 
         ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
         ssl_prefer_server_ciphers on;
         ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
 
         # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
         #ssl_dhparam /etc/nginx/ssl/dhparam.pem;
 
         include     /etc/nginx/proxy.conf;
 
         ## serve static files by Nginx, recommended for performance
         # location /_static/rhodecode {
         #    alias /path/to/.rccontrol/enterprise-1/static;
         # }
 
         ## channelstream websocket handling
         location /_channelstream {
             rewrite /_channelstream/(.*) /$1 break;
 
             proxy_pass                  http://127.0.0.1:9800;
 
             proxy_connect_timeout        10;
             proxy_send_timeout           10m;
             proxy_read_timeout           10m;
             tcp_nodelay                  off;
             proxy_set_header             Host $host;
             proxy_set_header             X-Real-IP $remote_addr;
             proxy_set_header             X-Url-Scheme $scheme;
             proxy_set_header             X-Forwarded-Proto $scheme;
             proxy_set_header             X-Forwarded-For $proxy_add_x_forwarded_for;
             gzip                         off;
             proxy_http_version           1.1;
             proxy_set_header Upgrade     $http_upgrade;
             proxy_set_header Connection  "upgrade";
         }
 
         location /_admin/login {
             ## rate limit this endpoint
             limit_req  zone=dl_limit  burst=10  nodelay;
             try_files $uri @rhode;
         }
 
         location / {
             try_files $uri @rhode;
         }
 
         location @rhode {
             proxy_pass      http://rc;
         }
 
         ## custom 502 error page
         error_page 502 /502.html;
         location = /502.html {
            root  /path/to/.rccontrol/enterprise-1/static;
         }
     }
  No newline at end of file

docs/api/methods/deprecated-methods.rst

@@ -1,77 +1,77 b''
 .. _deprecated-methods-ref:
 
 deprecated methods
 ==================
 
 changeset_comment 
 -----------------
 
 .. py:function:: changeset_comment(apiuser, repoid, revision, message, userid=<Optional:<OptionalAttr:apiuser>>, status=<Optional:None>)
 
    .. deprecated:: 3.4.0
 
           Please use method `comment_commit` instead.
 
 
    Set a changeset comment, and optionally change the status of the
    changeset.
 
    This command can only be run using an |authtoken| with admin
    permissions on the |repo|.
 
    :param apiuser: This is filled automatically from the |authtoken|.
    :type apiuser: AuthUser
    :param repoid: Set the repository name or repository ID.
    :type repoid: str or int
    :param revision: Specify the revision for which to set a comment.
    :type revision: str
    :param message: The comment text.
    :type message: str
    :param userid: Set the user name of the comment creator.
    :type userid: Optional(str or int)
    :param status: Set the comment status. The following are valid options:
        * not_reviewed
        * approved
        * rejected
        * under_review
    :type status: str
 
    Example error output:
 
-   .. code-block:: json
+   .. code-block:: javascript
 
        {
-           "id" : <id_given_in_input>,
+           "id" : "<id_given_in_input>",
            "result" : {
                "msg": "Commented on commit `<revision>` for repository `<repoid>`",
-               "status_change": null or <status>,
+               "status_change": null or "<status>",
                "success": true
            },
            "error" : null
        }
 
 
 get_locks 
 ---------
 
 .. py:function:: get_locks(apiuser, userid=<Optional:<OptionalAttr:apiuser>>)
 
    .. deprecated:: 4.0.0
 
       Please use method `get_user_locks` instead.
 
    None
 
 
 show_ip 
 -------
 
 .. py:function:: show_ip(apiuser, userid=<Optional:<OptionalAttr:apiuser>>)
 
    .. deprecated:: 4.0.0
 
       Please use method `get_ip` instead.
 
    None
 
 

docs/contributing/contributing.rst

@@ -1,21 +1,26 b''
 .. _contributing:
 
 Contributing to RhodeCode
 =========================
 
 
 
 Welcome to the contribution guides and development docs of RhodeCode.
 
 
 
 .. toctree::
    :maxdepth: 1
 
    overview
    testing/index
    dev-setup
    db-schema
    dev-settings
    api
    dependencies
+   checklist-tickets
+   checklist-pull-request
+   frontend
+   standards
+

docs/integrations/ci.rst

@@ -1,97 +1,97 b''
 .. _integrations-ci:
 
 CI Server integration
 =====================
 
 
 RhodeCode :ref:`integrations-webhook` integration is a powerfull tool to allow
 interaction with systems like Jenkin, Bamboo, TeamCity, CircleCi or any other
 CI server that allows triggering a build using HTTP call.
 
 Below are few examples on how to use :ref:`integrations-webhook` to trigger
 a CI build.
 
 
 General Webhook
 +++++++++++++++
 
 :ref:`integrations-webhook` allows sending a JSON payload information to specified
 url with GET or POST methods. There are several variables that could be used
 in the URL greatly extending the flexibility of this type of integration.
 
 Most of the modern CI systems such as Jenkins, TeamCity, Bamboo or CircleCi
 allows triggering builds via GET or POST calls.
 
 :ref:`integrations-webhook` can be either specified per each repository or
 globally, if your CI maps directly to all your projects a global
 :ref:`integrations-webhook` integration can be created and will trigger builds
 for each change in projects. If only some projects allow triggering builds a
 global integration will also work because mostly a CI system will ignore a
 call for unspecified builds.
 
 
 .. note::
 
     A quick note on security. It's recommended to allow IP restrictions
     to only allow RhodeCode server to trigger builds. If you need to
     specify username and password this could be done by embedding it into a
-    trigger URL, e.g. `http://user:[e-mail]/job/${project_id}
+    trigger URL, e.g. `http://user:[e-mail]/job/${project_id}`
 
 
 If users require to provide any custom parameters, they can be stored for each
 project inside the :ref:`repo-xtra`. For example to migrate a current job that
 has a numeric build id, storing this as `jenkins_build_id` key extra field
 the url would look like that::
 
     http://server/job/${extra:jenkins_build_id}/
 
 
 .. note::
 
     Please note that some variables will result in multiple calls.
     e.g. for |HG| specifying `${branch}` will trigger as many builds as how
     many branches the suer actually pushed. Same applies to `${commit_id}`
     This will trigger many builds if many commits are pushed. This allows
     triggering individual builds for each pushed commit.
 
 
 Jenkins
 +++++++
 
 To use Jenkins CI with RhodeCode, a Jenkins Build with Parameters should be used.
 Plugin details are available here: https://wiki.jenkins.io/display/JENKINS/Build+With+Parameters+Plugin
 
 If the plugin is configured, RhodeCode can trigger builds automatically by
 calling such example url provided in :ref:`integrations-webhook` integration::
 
     http://server/job/${project_id}/build-branch-${branch}/buildWithParameters?token=TOKEN&PARAMETER=value&PARAMETER2=value2
 
 
 Team City
 +++++++++
 
 To use TeamCity CI it's enough to call the API and provide a buildId.
 Example url after configuring :ref:`repo-xtra` would look like that::
 
     http://teacmtiyserver/viewType.html?buildTypeId=${extra:tc_build_id}
 
 
 Each project can have many build configurations.
 buildTypeId which is a unique ID for each build configuration (job).
 
 
 CircleCi
 ++++++++
 
 To use CircleCi, a POST call needs to be triggered. Example build url would
 look like this::
 
     http://cicleCiServer/project/${repo_type}/${username}/${repo_id}/tree/${branch}
 
 
 Circle Ci expects format of::
 
     POST: /project/:vcs-type/:username/:project/tree/:branch
 
 
 CircleCi API documentation can be found here: https://circleci.com/docs/api/v1-reference/

docs/integrations/integrations.rst

@@ -1,54 +1,55 b''
 .. _integrations:
 
 Integrations
 ------------
 
 Rhodecode supports integrations with external services for various events,
 such as commit pushes and pull requests. Multiple integrations of the same type
 can be added at the same time; this is useful for posting different events to
 different Slack channels, for example.
 
 Supported integrations
 ^^^^^^^^^^^^^^^^^^^^^^
 
 ============================    ============    =====================================
 Type/Name                       |RC| Edition    Description
 ============================    ============    =====================================
 :ref:`integrations-slack`       |RCCEshort|     https://slack.com/
 :ref:`integrations-hipchat`     |RCCEshort|     https://www.hipchat.com/
 :ref:`integrations-webhook`     |RCCEshort|     POST events as `json` to a custom url
 :ref:`integrations-ci`          |RCCEshort|     Trigger Builds for Common CI Systems
 :ref:`integrations-email`       |RCCEshort|     Send repo push commits by email
 :ref:`integrations-redmine`     |RCEEshort|     Close/Resolve/Reference redmine issues
 :ref:`integrations-jira`        |RCEEshort|     Close/Resolve/Reference JIRA issues
 ============================    ============    =====================================
 
 .. _creating-integrations:
 
 Creating an Integration
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Integrations can be added globally via the admin UI:
 
 :menuselection:`Admin --> Integrations`
 
 or per repository in each repository's settings:
 
 :menuselection:`Admin --> Repositories --> Edit --> Integrations`
 
 To create an integration, select the type from the list in the *Create New
 Integration* section.
 
 The *Current Integrations* section shows existing integrations that have been
 created along with their type (eg. Slack) and enabled status.
 
 See pages specific to each type of integration for more instructions:
 
 .. toctree::
 
    slack
    hipchat
    redmine
    jira
    webhook
    email
+   ci

docs/tutorials/api-examples.rst

@@ -1,66 +1,65 b''
 .. _api-ex:
 
 API Example Usage
 =================
 
 Use the following example uses of the |RCE| API to carry out work on your
 instances, or |repo| maintanence on the server. For the complete API
 documentation, see the :ref:`api` section.
 
 .. _api-strip:
 
 Stripping Commits
 -----------------
 
 The strip command is useful for removing commits on the server, allowing
 you to push changes without using force. To strip commits on the server, use
 the following steps:
 
 1. Install |RCT|, as explained in the :ref:`install-tools` section.
 2. Configure the :file:`~/.rhoderc` file with the API connection details, as
    explained in the :ref:`config-rhoderc` section.
 3. Check the |RCE| changelog and see from which revision onwards you wish to
    strip commits. This will also strip all descendants.
 
 .. image:: ../images/pre-strip.png
 
 
 4. Enter your |RCT| virtual environment, using the following example:
 
 .. code-block:: bash
 
     $ . venv/bin/activate
     (venv)$
 
 5. Use the API to strip a commit, or number of commits from a |repo|. In this
    example I am stripping the top two commits from ``ad1e0523a4ab`` onwards.
 
 .. note::
 
    Repositories in |repo| groups require the |repo| group to be passed as
    part of the ``repoid``.
 
 .. code-block:: bash
 
     # Run the Strip API call
     $ rhodecode-api --instance-name=instance-id strip \
         repoid:repo-group/repo-name revision:ad1e0523a4ab branch:stable
 
     # Check the JSON-RPC verification
 
-.. code-block:: jsonld
+.. code-block:: javascript
 
     {
       "error": null,
       "id": 5960,
       "result": {
-        "msg": "Stripped commit ad1e0523a4ab from
-            repo `repo-group/repo-name`",
+        "msg": "Stripped commit ad1e0523a4ab from repo `repo-group/repo-name`",
         "repository": "repo-group/repo-name"
       }
     }
 
 6. Once the commits are stripped, you can verify that they are
    stripped on the web interface.
 
 .. image:: ../images/post-strip.png