Reorganize and expand documentation
This commit is contained in:
Rehan Dalal
Родитель
2b0b926a88
Коммит
2aa56ed121
|
|
@ -1,14 +0,0 @@
|
|||
==============
|
||||
Authentication
|
||||
==============
|
||||
|
||||
By default, the authentication will be done against the ``auth.mozilla.auth0.com`` instance hosted
|
||||
by Auth0.com.
|
||||
|
||||
To override how the OpenID Connection authentication should be done set
|
||||
``REACT_APP_OIDC_CLIENT_ID`` and ``REACT_APP_OIDC_DOMAIN`` either by typing it into a file called
|
||||
``.env`` or you can do it on the command line when starting the development server. E.g.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ REACT_APP_OIDC_DOMAIN=my.oidc.domain.example.com REACT_APP_OIDC_CLIENT_ID=6YRYpJyS5DnDyxLTRVGCQGCWGo2KNQLX yarn start
|
||||
12
docs/ci.rst
12
docs/ci.rst
|
|
@ -1,12 +0,0 @@
|
|||
======================
|
||||
Continuous Integration
|
||||
======================
|
||||
|
||||
All code is tested with `CircleCI`_. All pull requests runs the
|
||||
unit tests and attempts to build.
|
||||
|
||||
The `CircleCI`_ is also used to deploy the built code into Dev, Stage and
|
||||
Production.
|
||||
|
||||
|
||||
.. _`CircleCI`: https://circleci.com/gh/mozilla/delivery-console
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
Configuration
|
||||
=============
|
||||
All configuration happens through environment variables.
|
||||
|
||||
Delivery Console settings
|
||||
-------------------------
|
||||
An environment variable like ``REACT_APP_FOO`` controls the setting ``FOO``.
|
||||
|
||||
.. envvar:: REACT_APP_SENTRY_PUBLIC_DSN
|
||||
|
||||
:default: ``null``
|
||||
|
||||
Optional. The DSN for Raven to report errors to Sentry.
|
||||
|
||||
.. envvar:: REACT_APP_NORMANDY_ADMIN_API_ROOT_URL
|
||||
|
||||
:default: ``https://localhost:8000/api/``
|
||||
|
||||
The root url for the Normandy API that should be used for users with
|
||||
access to the Normandy admin.
|
||||
|
||||
.. envvar:: REACT_APP_NORMANDY_READ_ONLY_API_ROOT_URL
|
||||
|
||||
:default: ``null``
|
||||
|
||||
The root url for the Normandy API that should be used for users with out
|
||||
access to the Normandy admin. It will be used as a fallback in case the
|
||||
admin server is inaccesible.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_CLIENT_ID
|
||||
|
||||
:default: ``hU1YpGcL82wL04vTPsaPAQmkilrSE7wr``
|
||||
|
||||
The Auth0 client ID to be used when authenticating.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_DOMAIN
|
||||
|
||||
:default: ``auth.mozilla.auth0.com``
|
||||
|
||||
The Auth0 domain to use for authenticating the user.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_CALLBACK_URL
|
||||
|
||||
:default: The TLD origin for the current URL
|
||||
|
||||
The URL to redirect users back to after the Auth0 authentication dance is complete.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_AUDIENCE
|
||||
|
||||
:default: ``https://${OIDC_DOMAIN}/userinfo``
|
||||
|
||||
The audience for the access token that is generated by Auth0.
|
||||
|
||||
|
||||
.. envvar:: REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS
|
||||
|
||||
:default: 300
|
||||
|
||||
How often to issue a silent authentication refresh. Technically, when you're logged in,
|
||||
an infinite loop is run that refreshes your access token forever. And this number is
|
||||
the number of seconds to sleep between each check.
|
||||
This number is also used to preemptively trigger a refresh. Meaning, if the access token
|
||||
hasn't yet expired but it will *in* ``REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS``
|
||||
seconds, that triggers a authentication refresh too.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
=======
|
||||
Console
|
||||
=======
|
||||
|
||||
The main app that holds together all the other apps.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
============
|
||||
Contributing
|
||||
============
|
||||
|
||||
Be nice and make great things.
|
||||
|
||||
See https://github.com/mozilla/delivery-console/issues/9
|
||||
125
docs/dev.rst
125
docs/dev.rst
|
|
@ -1,125 +0,0 @@
|
|||
=======================
|
||||
Developer Documentation
|
||||
=======================
|
||||
|
||||
You need your own ``yarn`` and a recent version of NodeJS. To get started
|
||||
right away run:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ git clone https://github.com/mozilla/delivery-console.git
|
||||
$ cd delivery-console
|
||||
$ yarn
|
||||
$ yarn start
|
||||
|
||||
Now you should be able to open ``http://localhost:3000`` and behold the
|
||||
aweomeness.
|
||||
|
||||
Standalone App Configuration
|
||||
============================
|
||||
|
||||
When working on an individual app, there is a need to stub out certain values/props that would normally be passed in through the delivery-console. These props include authTokens, usernames, etc. When working on an app on its own, these values are stubbed out when the component is mounted to the DOM. Consider the following example:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
/*
|
||||
fake-app/App.js
|
||||
|
||||
The entry point to the app when nested in the delivery-console. This contains the basic component definition for the app, and is written as a normal React component.
|
||||
*/
|
||||
import React from 'react';
|
||||
import './App.css';
|
||||
|
||||
export default class App extends React.Component {
|
||||
render() {
|
||||
return (
|
||||
<div>
|
||||
<h1>Welcome to this app!</h1>
|
||||
<p>The prop value being passed in is set to "{ this.props.someProp }"</p>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
/*
|
||||
fake-app/index.js
|
||||
|
||||
The entry point to the app when standing up alone. This is useful for stubbing out values that would be passed down from the delivery-console (such as an authToken).
|
||||
*/
|
||||
import React from 'react';
|
||||
import ReactDOM from 'react-dom';
|
||||
import FakeApp from './App';
|
||||
|
||||
ReactDOM.render(
|
||||
<FakeApp someProp="some-value" />,
|
||||
document.getElementById('root'),
|
||||
);
|
||||
|
||||
``App.js`` outlines the actual React component for the app, while ``index.js`` mounts the app to the DOM with some fake data.
|
||||
|
||||
|
||||
FSEvent Errors Running ``jest``
|
||||
===============================
|
||||
|
||||
If you encounter an error like this, when running ``yarn run test:jest``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
▶ yarn run test:jest
|
||||
yarn run v1.7.0
|
||||
$ react-app-rewired test --env=jsdom
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
events.js:167
|
||||
throw er; // Unhandled 'error' event
|
||||
^
|
||||
|
||||
Error: EMFILE: too many open files, watch
|
||||
at FSEvent.FSWatcher._handle.onchange (fs.js:1372:28)
|
||||
Emitted 'error' event at:
|
||||
at FSEvent.FSWatcher._handle.onchange (fs.js:1378:12)
|
||||
error Command failed with exit code 1.
|
||||
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
|
||||
|
||||
A probable cause is that you don't have ``watchman`` installed. For example, on macOS you can fix this by installing...:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ brew update
|
||||
$ brew install watchman
|
||||
|
||||
Debugging Silent Authentication
|
||||
===============================
|
||||
|
||||
The way the authentication works is that a never-ending loop checks if the access token has
|
||||
expired, or is about to expire. Actually, it only uses ``localStorage.expiresAt`` to do this.
|
||||
To debug this you can either sit very patiently and wait till the check ticks again, or you
|
||||
can speed it up manually. First, to control how often the check ticks, you can override
|
||||
``REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS`` when starting the dev server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS=10 yarn start
|
||||
|
||||
That will cause the check to run every 10 seconds.
|
||||
|
||||
Secondly, to avoid awaiting for the access token to expire, you can paste this function
|
||||
into the Web Console:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
window.windExpires = hours => {
|
||||
let expires = JSON.parse(localStorage.getItem('expiresAt')) - hours * 1000 * 3600;
|
||||
localStorage.setItem('expiresAt', JSON.stringify(expires));
|
||||
};
|
||||
|
||||
Now you can type, in the Web Console:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
windExpires(1.5)
|
||||
|
||||
That will simulate that 1.5 hours on the ``localStorage.expiresAt`` has gone past.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
Authentication
|
||||
==============
|
||||
|
||||
By default, the authentication will be done against the
|
||||
``auth.mozilla.auth0.com`` instance hosted by Auth0.com.
|
||||
|
||||
To override how the OpenID Connection authentication should be done set
|
||||
``REACT_APP_OIDC_CLIENT_ID`` and ``REACT_APP_OIDC_DOMAIN`` either by typing it
|
||||
into a file called ``.env`` or you can do it on the command line when starting
|
||||
the development server.
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ REACT_APP_OIDC_DOMAIN=my.oidc.domain.example.com REACT_APP_OIDC_CLIENT_ID=6YRYpJyS5DnDyxLTRVGCQGCWGo2KNQLX yarn start
|
||||
|
||||
Debugging Silent Authentication
|
||||
-------------------------------
|
||||
The way the authentication works is that a never-ending loop checks if the
|
||||
access token has expired, or is about to expire. Actually, it only uses
|
||||
``localStorage.expiresAt`` to do this. To debug this you can either sit very
|
||||
patiently and wait till the check ticks again, or you can speed it up manually.
|
||||
First, to control how often the check ticks, you can override
|
||||
``REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS`` when starting the dev server:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS=10 yarn start
|
||||
|
||||
That will cause the check to run every 10 seconds.
|
||||
|
||||
Secondly, to avoid awaiting for the access token to expire, you can paste this
|
||||
function into the Web Console:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
window.windExpires = hours => {
|
||||
let expires = JSON.parse(localStorage.getItem('expiresAt')) - hours * 1000 * 3600;
|
||||
localStorage.setItem('expiresAt', JSON.stringify(expires));
|
||||
};
|
||||
|
||||
Now you can type, in the Web Console:
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
windExpires(1.5)
|
||||
|
||||
That will simulate that 1.5 hours on the ``localStorage.expiresAt`` has gone
|
||||
past.
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
=====================
|
||||
Code Style Guidelines
|
||||
=====================
|
||||
|
||||
Goals
|
||||
=====
|
||||
|
||||
* Uniformity in code
|
||||
* If you look at code and can tell who wrote it, that’s not good
|
||||
* Rules should be automatable
|
||||
* Code should be easy to read / understand
|
||||
|
||||
Rules
|
||||
=====
|
||||
|
||||
Prettier formatting (uniformity)
|
||||
--------------------------------
|
||||
|
||||
Delivery Console uses `Prettier`_ to format code. If you set up the
|
||||
:ref:`Therapist <therapist-install>` pre-commit hook, it can handle formatting
|
||||
your code automatically.
|
||||
|
||||
.. _Prettier: https://prettier.io/
|
||||
|
||||
Commenting (uniformity)
|
||||
-----------------------
|
||||
|
||||
Function documentation (jsdoc/docstrings)
|
||||
|
||||
.. code-block:: javascript
|
||||
|
||||
/**
|
||||
* Given an option and its parent group, update the filter state based on the `isEnabled` prop
|
||||
*
|
||||
* @param {Object} group
|
||||
* @param {Object} option
|
||||
* @param {Boolean} isEnabled
|
||||
*/
|
||||
function selectFilter({ group, option, isEnabled }) {
|
||||
return {
|
||||
type: group.value === 'text' ? SET_TEXT_FILTER : SET_FILTER,
|
||||
group,
|
||||
option,
|
||||
isEnabled,
|
||||
};
|
||||
}
|
||||
|
||||
**Rule: Use full width for wrapping comments (80-100 chars)**
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
Local Configuration
|
||||
===================
|
||||
|
||||
There are a number of :doc:`configuration variables </ops/config>` that can be
|
||||
overridden.
|
||||
|
||||
For local configuration, variables can simply be passed on the command line when
|
||||
starting the development server:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ REACT_APP_OIDC_DOMAIN=my.oidc.domain.example.com yarn start
|
||||
|
||||
However, it is recommended that you create a ``.env`` file in the root of the
|
||||
project instead. For example:
|
||||
|
||||
.. code-block::
|
||||
|
||||
REACT_APP_OIDC_DOMAIN=my.oidc.domain.example.com
|
||||
REACT_APP_OIDC_CLIENT_ID=6YRYpJyS5DnDyxLTRVGCQGCWGo2KNQLX
|
||||
|
|
@ -1,36 +1,35 @@
|
|||
==========================
|
||||
Updating The Documentation
|
||||
==========================
|
||||
|
||||
You need to have Python to build the documentation locally.
|
||||
|
||||
The documentation is built automatically in our continuous integration
|
||||
every time a commit is pushed.
|
||||
The documentation is built automatically in our continuous integration every
|
||||
time a commit is pushed.
|
||||
|
||||
To build the documentation, create and activate a Python virtualenv.
|
||||
For exampe:
|
||||
For example:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
$ virtualenv -p `which python3.6` .venv
|
||||
$ source .venv/bin/activate
|
||||
$ virtualenv -p `which python3.6` .venv
|
||||
$ source .venv/bin/activate
|
||||
|
||||
Now install the Sphinx packages:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
(.venv) $ pip install -r docs/requirements.txt
|
||||
(.venv) $ pip install -r docs/requirements.txt
|
||||
|
||||
Now you should be able to build:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
(.venv) $ cd docs
|
||||
(.venv) $ make html
|
||||
(.venv) $ cd docs
|
||||
(.venv) $ make html
|
||||
|
||||
Watch out for build errors but if all goes well, you can now open
|
||||
the built HTML files in your browser. E.g.:
|
||||
Watch out for build errors but if all goes well, you can now open the built HTML
|
||||
files in your browser. E.g.:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
(.venv) $ open _build/html/index.html
|
||||
(.venv) $ open _build/html/index.html
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
Developer Documentation
|
||||
=======================
|
||||
These documents describe how to set up Delivery Console and maintain a
|
||||
development environment for it.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
install
|
||||
configuration
|
||||
workflow
|
||||
code-style
|
||||
documentation
|
||||
authentication
|
||||
troubleshooting
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
Developer Setup
|
||||
===============
|
||||
|
||||
The following describes how to set up an instance of the site on your
|
||||
computer for development.
|
||||
|
||||
Prerequisites
|
||||
-------------
|
||||
This guide assumes you have already installed and set up the following:
|
||||
|
||||
1. Git_
|
||||
2. `Node.js 8`_ and `Yarn`_.
|
||||
3. `Python 2.7`_ or higher and`pip 8`_ or higher
|
||||
|
||||
These docs assume a Unix-like operating system, although the site should, in
|
||||
theory, run on Windows as well. All the example commands given below are
|
||||
intended to be run in a terminal.
|
||||
|
||||
.. _Git: https://git-scm.com/
|
||||
.. _Node.js 8: https://nodejs.org/en/
|
||||
.. _Yarn: https://yarnpkg.com/en/
|
||||
.. _Python 2.7: https://www.python.org/
|
||||
.. _pip 8: https://pip.pypa.io/en/stable/
|
||||
|
||||
Installation
|
||||
------------
|
||||
1. Clone this repository or your fork_:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git clone https://github.com/mozilla/delivery-console.git
|
||||
cd delivery-console
|
||||
|
||||
2. Install the dependencies using yarn:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
yarn install
|
||||
|
||||
Once you've finished these steps, you should be able to start the site by
|
||||
running:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
yarn start
|
||||
|
||||
The site should be available at http://localhost:3000/.
|
||||
|
||||
.. _fork: http://help.github.com/fork-a-repo/
|
||||
|
||||
.. _therapist-install:
|
||||
|
||||
Therapist
|
||||
---------
|
||||
If you want to automatically enforce Delivery Console's code style guidelines,
|
||||
you can use the `Therapist`_ pre-commit hook. To install Therapist, simply run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install therapist
|
||||
|
||||
After that, you should be able to run the following to set up the git
|
||||
pre-commit hook:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist install
|
||||
|
||||
After that, whenever you make a new commit Therapist will check the changed
|
||||
code. This will save time when submitting pull requests.
|
||||
|
||||
If you want Therapist to attempt to automatically fix linting issues you can
|
||||
install the hook using:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist install --fix
|
||||
|
||||
If you ever need to bypass Therapist, you can do so by passing
|
||||
``--no-verify`` to your ``git commit`` command.
|
||||
|
||||
.. _Therapist: http://therapist.readthedocs.io/en/latest/overview.html
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
Workflow
|
||||
========
|
||||
|
||||
The following is a list of things you'll probably need to do at some point while
|
||||
working on Delivery Console.
|
||||
|
||||
Running Tests
|
||||
-------------
|
||||
You can run the automated test suite with the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
yarn test
|
||||
|
||||
If you'd prefer that the tests watch for changes and re-run automatically:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
yarn test:watch
|
||||
|
||||
.. note::
|
||||
|
||||
If you encounter an error like this, when running ``yarn test:watch``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
▶ yarn run test:jest
|
||||
yarn run v1.7.0
|
||||
$ react-app-rewired test --env=jsdom
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
2018-06-20 13:55 node[6928] (FSEvents.framework) FSEventStreamStart: register_with_server: ERROR: f2d_register_rpc() => (null) (-22)
|
||||
events.js:167
|
||||
throw er; // Unhandled 'error' event
|
||||
^
|
||||
|
||||
Error: EMFILE: too many open files, watch
|
||||
at FSEvent.FSWatcher._handle.onchange (fs.js:1372:28)
|
||||
Emitted 'error' event at:
|
||||
at FSEvent.FSWatcher._handle.onchange (fs.js:1378:12)
|
||||
error Command failed with exit code 1.
|
||||
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
|
||||
|
||||
A probable cause is that you don't have ``watchman`` installed. For example,
|
||||
on macOS you can fix this by installing...:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ brew update
|
||||
$ brew install watchman
|
||||
|
||||
Linting
|
||||
-------
|
||||
You will need to :ref:`install Therapist <therapist-install>` for linting. If
|
||||
you have installed pre-commit hook linting will take place with every commit,
|
||||
however there may be times you want to run the linters manually.
|
||||
|
||||
To run the linters on all files that you have changed or added:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist use lint
|
||||
|
||||
To run the linters on all files in the repo:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist use lint:all
|
||||
|
||||
To run the linters and attempt to fix issues in files that you have changed or
|
||||
added:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist use fix
|
||||
|
||||
To run the linters and attempt to fix issues in all files in the repo:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
therapist use fix:all
|
||||
|
||||
Production Builds
|
||||
-----------------
|
||||
If you need a production build to debug locally you can create one using:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
yarn build
|
||||
|
||||
Redux DevTools
|
||||
--------------
|
||||
In development mode we have integrated `Redux DevTools`_ to help debug issues.
|
||||
To toggle the DevTools, hit ``Ctrl-H``. You can change the side of the screen
|
||||
the tools are docked on using ``Ctrl-Q``, and can resize the tools by dragging
|
||||
the edge of the bar.
|
||||
|
||||
.. _Redux DevTools: https://github.com/gaearon/redux-devtools
|
||||
|
|
@ -2,35 +2,11 @@
|
|||
Mozilla Delivery Console
|
||||
========================
|
||||
|
||||
|
||||
One admin interface to rule them all.
|
||||
|
||||
Contents
|
||||
========
|
||||
|
||||
User docs:
|
||||
Delivery Console is a unified admin UI for the many delivery pipelines to the
|
||||
browser.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
console
|
||||
normandy
|
||||
|
||||
|
||||
Project docs:
|
||||
|
||||
.. toctree::
|
||||
|
||||
dev
|
||||
config
|
||||
contributing
|
||||
auth
|
||||
ci
|
||||
docs
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
dev/index
|
||||
ops/index
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
========
|
||||
Normandy
|
||||
========
|
||||
|
||||
Manage your Shield studies through Normandy in this app.
|
||||
|
||||
More about how to gain access, rules, teams to talk to, authorization,
|
||||
scripting, etc.
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
Configuration
|
||||
=============
|
||||
All configuration happens through environment variables.
|
||||
|
||||
Delivery Console settings
|
||||
-------------------------
|
||||
An environment variable like ``REACT_APP_FOO`` controls the setting ``FOO``.
|
||||
|
||||
.. envvar:: REACT_APP_SENTRY_PUBLIC_DSN
|
||||
|
||||
:default: ``null``
|
||||
|
||||
Optional. The DSN for Raven to report errors to Sentry.
|
||||
|
||||
.. envvar:: REACT_APP_NORMANDY_ADMIN_API_ROOT_URL
|
||||
|
||||
:default: ``https://localhost:8000/api/``
|
||||
|
||||
The root url for the Normandy API that should be used for users with
|
||||
access to the Normandy admin.
|
||||
|
||||
.. envvar:: REACT_APP_NORMANDY_READ_ONLY_API_ROOT_URL
|
||||
|
||||
:default: ``null``
|
||||
|
||||
The root url for the Normandy API that should be used for users with out
|
||||
access to the Normandy admin. It will be used as a fallback in case the
|
||||
admin server is inaccesible.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_CLIENT_ID
|
||||
|
||||
:default: ``hU1YpGcL82wL04vTPsaPAQmkilrSE7wr``
|
||||
|
||||
The Auth0 client ID to be used when authenticating.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_DOMAIN
|
||||
|
||||
:default: ``auth.mozilla.auth0.com``
|
||||
|
||||
The Auth0 domain to use for authenticating the user.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_CALLBACK_URL
|
||||
|
||||
:default: The TLD origin for the current URL
|
||||
|
||||
The URL to redirect users back to after the Auth0 authentication dance is
|
||||
complete.
|
||||
|
||||
.. envvar:: REACT_APP_OIDC_AUDIENCE
|
||||
|
||||
:default: ``https://${OIDC_DOMAIN}/userinfo``
|
||||
|
||||
The audience for the access token that is generated by Auth0.
|
||||
|
||||
|
||||
.. envvar:: REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS
|
||||
|
||||
:default: 300
|
||||
|
||||
How often to issue a silent authentication refresh. Technically, when you're
|
||||
logged in, an infinite loop is run that refreshes your access token forever.
|
||||
And this number is the number of seconds to sleep between each check.
|
||||
|
||||
This number is also used to preemptively trigger a refresh. Meaning, if the
|
||||
access token hasn't yet expired but it will *in*
|
||||
``REACT_APP_CHECK_AUTH_EXPIRY_INTERVAL_SECONDS`` seconds, that triggers a
|
||||
authentication refresh too.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Operations Documentation
|
||||
========================
|
||||
These documents relate to deploying and maintaining Deliver Console in a server
|
||||
environment.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
config
|
||||
Загрузка…
Ссылка в новой задаче