e3fee2cf46
Prior to this commit, the Odoo documentation was mainly split between
two repositories: odoo/odoo/doc and odoo/documentation-user. Some bits
of documentation were also hosted elsewhere (e.g., wiki, upgrade, ...).
This was causing several problems among which:
- The theme, config, Makefile, and similar technical resources had to
be duplicated. This resulted in inconsistent layout, features, and
build environments from one documentation to another.
- Some pages did not fit either documentation as they were relevant
for both users and developers. Some were relevant to neither of the
two (e.g., DB management).
- Cross-doc references had to be absolute links and they broke often.
- Merging large image files in the developer documentation would bloat
the odoo/odoo repository. Some contributions had to be lightened to
avoid merging too many images (e.g., Odoo development tutorials).
- Long-time contributors to the user documentation were chilly about
going through the merging process of the developer documentation
because of the runbot, mergebot, `odoo-dev` repository, etc.
- Some contributors would look for the developer documentation in the
`odoo/documentation-user` repository.
- Community issues about the user documentation were submitted on the
`odoo/odoo` repository and vice-versa.
Merging all documentations in one repository will allow us to have one
place, one theme, one work process, and one set of tools (build
environment, ...) for all of the Odoo docs.
As this is a good opportunity to revamp the layout of the documentation,
a brand new theme replaces the old one. It features a new way to
navigate the documentation, centered on the idea of always letting the
reader know what is the context (enclosing section, child pages, page
structure ...) of the page they are reading. The previous theme would
quickly confuse readers as they navigated the documentation and followed
cross-application links.
The chance is also taken to get rid of all the technical dangling parts,
performance issues, and left-overs. Except for some page-specific JS
scripts, the Odoo theme Sphinx extension is re-written from scratch
based on the latest Sphinx release to benefit from the improvements and
ease future contributions.
task-2351938
task-2352371
task-2205684
task-2352544
Closes #945
124 lines
5.2 KiB
ReStructuredText
124 lines
5.2 KiB
ReStructuredText
|
|
.. _odoosh-gettingstarted-builds:
|
|
|
|
==================================
|
|
Builds
|
|
==================================
|
|
|
|
Overview
|
|
========
|
|
|
|
In Odoo.sh, a build is considered as a database loaded by an Odoo server
|
|
(`odoo/odoo <https://github.com/odoo/odoo>`_ & `odoo/enterprise <https://github.com/odoo/enterprise>`_)
|
|
running on a specific revision of your project repository in a containerized environment.
|
|
Its purpose is to test the well-behavior of the server, the database and the features with this revision.
|
|
|
|
.. image:: ./media/interface-builds.png
|
|
:align: center
|
|
|
|
In this view, a row represents a branch, and a cell of a row represents a build of this branch.
|
|
|
|
Most of the time, builds are created following pushes on your Github repository branches.
|
|
They can be created as well when you do other operations,
|
|
such as importing a database on Odoo.sh or asking a rebuild for a branch in your project.
|
|
|
|
A build is considered successful if no errors or warnings come up during its creation.
|
|
A successful build is highlighted in green.
|
|
|
|
A build is considered failed if errors come up during its creation.
|
|
A failed build is highlighted in red.
|
|
|
|
If warnings come up during the creation, but there are no errors, the build is considered almost successful.
|
|
It is highlighted in yellow to notify the developer warnings were raised.
|
|
|
|
Builds do not always create a database from scratch.
|
|
For instance, when pushing a change on the production branch, the build created just starts the server
|
|
with your new revision and tries to load the current production database on it.
|
|
If no errors come up, the build is considered successful, and otherwise failed.
|
|
|
|
Stages
|
|
======
|
|
|
|
Production
|
|
----------
|
|
|
|
The first build of a production branch creates a database from scratch.
|
|
If this build is successful, this database is considered as the production database of your project.
|
|
|
|
From then, pushes on the production branch will create new builds that attempt to load the database
|
|
using a server running with the new revision.
|
|
|
|
If the build is successful, or has warnings but no errors, the production database will now run with this build, along
|
|
with the revision associated to this build.
|
|
|
|
If the build fails to load or update the database, then the previous successful build is re-used to load the database,
|
|
and therefore the database will run using a server running with the previous successful revision.
|
|
|
|
The build used to run the production database is always the first of the builds list. If a build fails, it is
|
|
put after the build currently running the production database.
|
|
|
|
Staging
|
|
-------
|
|
|
|
Staging builds duplicate the production database,
|
|
and try to load this duplicate with the revisions of the staging branches.
|
|
|
|
Each time you push a new revision on a staging branch, the build created uses a new copy of the production database.
|
|
The databases are not re-used between builds of the same branch. This ensures:
|
|
|
|
* staging builds use databases that are close to what the production looks like,
|
|
so you do not make your tests with outdated data,
|
|
|
|
* you can play around as much as you want in the same staging database,
|
|
and you can then ask for a rebuild when you want to restart with a new copy of the production.
|
|
|
|
Nevertheless, this means that if you make configuration changes in staging databases
|
|
and do not apply them in the production,
|
|
they will not be passed on the next build of the same staging branch.
|
|
|
|
Development
|
|
-----------
|
|
|
|
Development builds create new databases, load the demo data and run the unit tests.
|
|
|
|
A build will be considered failed and highlighted in red if tests fail during the installation,
|
|
as they are meant to raise errors if something wrong occurs.
|
|
|
|
If all tests pass, and there is no error, the build will be considered successful.
|
|
|
|
According to the list of modules to install and test, a development build can take up to 1 hour to be ready.
|
|
This is due to the large number of tests set in the default Odoo modules suite.
|
|
|
|
Features
|
|
========
|
|
|
|
The production branch will always appear first,
|
|
and then the other branches are ordered by last build created. You can filter out the branches.
|
|
|
|
.. image:: ./media/interface-builds-branches.png
|
|
:align: center
|
|
|
|
For each branch, you can access the last build's database using the *Connect* link and jump to the branch code using
|
|
the *Github* link. For other branches than the production, you can create a new build which will use the latest revision
|
|
of the branch using the link *rebuild*. This last link is not available when there is already a build in progress for
|
|
the branch.
|
|
|
|
.. image:: ./media/interface-builds-build.png
|
|
:align: center
|
|
|
|
For each build, you can access the revision changes using the button with the Github icon.
|
|
You can access the build's database as the administrator using the *Connect* button.
|
|
Also, you can access the database with another user using the *Connect as* button,
|
|
in the dropdown menu of the *Connect* button.
|
|
|
|
.. _odoosh-gettingstarted-builds-download-dump:
|
|
|
|
.. image:: ./media/interface-builds-build-dropdown.png
|
|
:align: center
|
|
|
|
.. _odoosh-gettingstarted-builds-dropdown-menu:
|
|
|
|
In the dropdown menu of the build, you can access the same features than in :ref:`the branches view <odoosh-gettingstarted-branches-tabs>`:
|
|
*Logs*, *Web Shell*, *Editor*, *Outgoing e-mails*.
|
|
You also have the possibility to *Download a dump* of the build's database.
|