[IMP] odoo_sh: small improvements proposition

This commit is contained in:
Fabien Meghazi 2018-03-28 17:32:25 +02:00 committed by Denis Ledoux
parent 20d242ef79
commit 56ef701a24
7 changed files with 43 additions and 37 deletions

View File

@ -140,7 +140,7 @@ with a browser, but you can for instance:
.. code-block:: bash
$ ~/src/odoo/odoo-bin shell -d odoo-addons-master-1 --addons-path=~/src/user,~/src/enterprise,~/src/themes,~/src/odoo/addons,~/src/odoo/odoo/addons --workers=0 --max-cron-threads=0
$ odoo-bin shell
>>> partner = env['res.partner'].search([('email', '=', 'asusteK@yourcompany.example.com')], limit=1)
>>> partner.name
'ASUSTeK'
@ -152,27 +152,24 @@ with a browser, but you can for instance:
.. code-block:: bash
$ ~/src/odoo/odoo-bin -d odoo-addons-master-1 --addons-path=~/src/user,~/src/enterprise,~/src/themes,~/src/odoo/addons,~/src/odoo/odoo/addons -i sale --workers=0 --max-cron-threads=0 --stop-after-init
$ odoo-bin -i sale --without-demo=all --stop-after-init
* update a module,
.. code-block:: bash
$ ~/src/odoo/odoo-bin -d odoo-addons-master-1 --addons-path=~/src/user,~/src/enterprise,~/src/themes,~/src/odoo/addons,~/src/odoo/odoo/addons -u sale --workers=0 --max-cron-threads=0 --stop-after-init
$ odoo-bin -u sale --stop-after-init
* run the tests for a module,
.. code-block:: bash
$ ~/src/odoo/odoo-bin -d odoo-addons-master-1 --addons-path=~/src/user,~/src/enterprise,~/src/themes,~/src/odoo/addons,~/src/odoo/odoo/addons -i sale --test-enable --log-level=test --workers=0 --max-cron-threads=0 --stop-after-init
$ odoo-bin -i sale --test-enable --log-level=test --stop-after-init
In the above commands, the argument:
* *--addons-path* is to specify the directories containing the modules,
the part *~/src/user* can vary, according to your branch code structure,
* *--workers=0* is to run your server using multi-threading instead of multiple workers,
* *--max-cron-threads=0* is to prevent the scheduled tasks to run,
* *--stop-after-init* is to immediately shutdown the server instance after it completed the operations you asked.
* ``--without-demo=all`` prevents demo data to be loaded for all modules
* ``--stop-after-init`` will immediately shutdown the server instance after it completed the operations you asked.
More options are available and detailed in the
`CLI documentation <https://www.odoo.com/documentation/11.0/reference/cmdline.html>`_.

View File

@ -19,10 +19,10 @@ as you can clone the repositories added as submodules at the same time you clone
Besides, you can choose the branch of the repository added as submodule
and you have the control of the revision you want.
It's up to you to decide wether you want to pin the submodule to a specific revision and when you want to update
It's up to you to decide whether you want to pin the submodule to a specific revision and when you want to update
to a newer revision.
In Odoo.sh, the submodules gives you the possibility to use and depends on modules available in other repositories.
In Odoo.sh, the submodules gives you the possibility to use and depend on modules available in other repositories.
The platform will detect that you added modules through submodules in your branches
and add them to your addons path automatically so you can install them in your databases.

View File

@ -35,7 +35,9 @@ your production server is updated with the code of the new revision and is then
If your changes require the update of a module, such as a change in a form view,
and you want it to be performed automatically,
increase the version number of the module in its manifest (*__manifest__.py*).
The platform will then take care to perform the update.
The platform will then take care to perform the update during which the
instance will be held temporarily unavailable for maintenance reason.
This method is equivalent to perform an upgrade of the module through the Apps menu,
or through the :code:`-u` switch of
@ -69,7 +71,7 @@ Be careful though: If these actions perform changes on third-party services (FTP
used by your production database as well,
you might cause unwanted changes in your production.
The databases created for staging branches are meant to live at least two weeks.
The databases created for staging branches are meant to live around two weeks.
After that, they can be garbage collected automatically.
If you make configuration changes or view changes in these branches, make sure to document them or write them directly
in the modules of the branch, using XML data files overriding the default configuration or views.
@ -81,7 +83,7 @@ Odoo.sh will then consider running the tests on staging databases.
Development
-----------
Development branches create new databases using the demo data and to run the unit tests.
Development branches create new databases using the demo data to run the unit tests.
The modules installed and tested by default are the ones included in your branches.
You can change this list of modules to install in your projects settings.
@ -92,7 +94,7 @@ This verifies your changes do not break any of the features tested by them.
Similar to staging branches, the emails are not sent: They are intercepted by the mailcatcher.
The databases created for development branches are meant to live at least three days.
The databases created for development branches are meant to live around three days.
After that, they can be garbage collected automatically.
.. _odoosh-gettingstarted-branches-mergingbranches:
@ -120,7 +122,7 @@ It just means you skip the validation of your changes with the production data t
You can merge your development branches into each other, and your staging branches into each other.
Of course, you can also use :code:`git merge` directly to merge your branches.
Of course, you can also use :code:`git merge` directly on your workstation to merge your branches.
Odoo.sh will be notified when new revisions have been pushed in your branches.
Merging a staging branch in the production branch only merges the source code: Any configuration changes you made in the
@ -174,6 +176,11 @@ and open a shell on your database by typing :code:`psql`.
.. image:: ./media/interface-branches-shell.png
:align: center
.. Note::
Long running shell instances are not guaranteed. Idle shells can be
disconnected at anytime in order to free up resources.
Logs
----
A viewer to have a look to your server logs.
@ -229,8 +236,10 @@ In the top right-hand corner of the view, different Git commands are available.
.. image:: ./media/interface-branches-gitcommands.png
:align: center
Each command be copied in the clipboard to be used in a terminal,
and some of them can be used directly from Odoo.sh by clicking the *run* button.
Each command can be copied in the clipboard to be used in a terminal,
and some of them can be used directly from Odoo.sh by clicking the *run* button
in such case a popup will prompt the user in order to define eventual placeholders
such as ``<URL>``, ``<PATH>``, ...
Clone
-----

View File

@ -11,7 +11,7 @@ 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.
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

View File

@ -9,7 +9,7 @@ Overview
This chapter helps you to create your first Odoo module and deploy it in your Odoo.sh project.
This tutorial requires :ref:`you created a project on Odoo.sh <odoosh-gettingstarted-create>`, and to know your Github repository URL.
This tutorial requires :ref:`you created a project on Odoo.sh <odoosh-gettingstarted-create>`, and you know your Github repository's URL.
Basic use of Git and Github is explained.
@ -54,7 +54,7 @@ It nevertheless requires *odoo-bin*, and therefore the
`installation of Odoo <https://www.odoo.com/documentation/11.0/setup/install.html#source-install>`_ on your machine.
If you do not want to bother installing Odoo on your machine,
you can also :download:`download this module structure template <media/my_module.zip>` in which you replace every occurences of
you can also :download:`download this module structure template <media/my_module.zip>` in which you replace every occurrences of
*my_module* to the name of your choice.
Use *odoo-bin scaffold* to generate the module structure in your repository:
@ -120,7 +120,7 @@ the structure of a module and the content of each file.
Push the development branch
===========================
Stage the changes to be commited
Stage the changes to be committed
.. code-block:: bash
@ -300,7 +300,7 @@ Add
<field name="start_datetime"/>
Stage your changes to be commited
Stage your changes to be committed
.. code-block:: bash
@ -381,7 +381,7 @@ Add
$ unidecode
Then use the library in your module, for instance to remove any special charaters in the name field of your
Then use the library in your module, for instance to remove any special characters in the name field of your
model.
Edit the file *models/models.py*
@ -448,7 +448,7 @@ Then stage, commit and push your changes
.. code-block:: bash
$ git add reqirements.txt
$ git add requirements.txt
$ git add my_module
$ git commit -m "[IMP] my_module: automatically remove special chars in my_module.my_module name field"
$ git push

View File

@ -7,7 +7,7 @@ Settings
Overview
========
The settings allow you to manage the configuration of your project.
The settings allows you to manage the configuration of your project.
.. image:: ./media/interface-settings.png
:align: center
@ -81,7 +81,7 @@ Allow public access to your development builds.
.. image:: ./media/interface-settings-public.png
:align: center
Expose the Builds page publicly, allowing visitors to connect to your development builds.
If activated, this option exposes the Builds page publicly, allowing visitors to connect to your development builds.
In addition, visitors have access to the logs, shell and mails of your development builds.
@ -119,19 +119,19 @@ If you would like to access your production database using your own domain name,
* own or purchase the domain name,
* add the domain name in this list,
* in your domain name manager,
configure the domain name with a CNAME record set to your production database domain name.
* in your registrar's domain name manager,
configure the domain name with a ``CNAME`` record set to your production database domain name.
For instance, to associate *www.mycompany.com* to your database *mycompany.odoo.com*:
* in Odoo.sh, add *www.mycompany.com* in the custom domains of your project settings,
* in your domain name manager (e.g. *godaddy.com*, *gandi.net*, *ovh.com*),
configure *www.mycompany.com* with a CNAME record with as value *mycompany.odoo.com*.
configure *www.mycompany.com* with a ``CNAME`` record with as value *mycompany.odoo.com*.
Bare domains (e.g. *mycompany.com*) are not accepted:
* they can only be configured using A records,
* A records only accept IP addresses as value,
* they can only be configured using ``A`` records,
* ``A`` records only accept IP addresses as value,
* the IP address of your database can change, following an upgrade, a hardware failure or
your wish to host your database in another country or continent.
@ -172,7 +172,7 @@ as submodules in your branches to allow Odoo.sh to download them.
When a repository is private, this is not possible to publicly download its branches and revisions.
For that reason, you need to configure a deploy key for Odoo.sh,
so the Git server allows our platform to download the revisions
so the remote Git server allows our platform to download the revisions
of this private repository.
To configure the deploy key for a private repository, proceed as follow:
@ -188,7 +188,7 @@ To configure the deploy key for a private repository, proceed as follow:
* in the settings of the private sub-repository, add the public key amongst the deploy keys.
* Github.com: Settings > Deploy keys > Add deploy key
* Bitbucket.com: Settings > Access keys > Add key
* Gitlab.com: Settings > Repository > Deploy Keys
* Github.com: :menuselection:`Settings --> Deploy keys --> Add deploy key`
* Bitbucket.com: :menuselection:`Settings --> Access keys --> Add key`
* Gitlab.com: :menuselection:`Settings --> Repository --> Deploy Keys`
* Self-hosted: append the key to the git users authorized_keys file in its .ssh directory

View File

@ -7,7 +7,7 @@ Status
Overview
========
The status page shows statistics regarding the servers your project use. It includes the servers availability.
The status page shows statistics regarding the servers your project uses. It includes the servers availability.
.. image:: ./media/interface-status.png
:align: center