[IMP] odoo_sh: small improvements proposition
This commit is contained in:
parent
20d242ef79
commit
56ef701a24
@ -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>`_.
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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
|
||||
-----
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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 user’s authorized_keys file in its .ssh directory
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user