Step to reproduce :
- run a V15 instance
- add a reference to 'OCA/geospatial' repo that doesn't contain any odoo module.
As a result, Odoo will exit with the following error:
odoo-bin: error: option --addons-path: the path '/odoo_env/src/OCA/geospatial' is not a valid addons directory
To avoid such problem, and avoid to have to remove empty repository
(that could become non empty in the future, and contains some migrations scripts),
- we reimplement a version of the odoo function _is_addons_path (odoo/odoo/tools/config.py)
- we add an info log :
Skipping addons path '.../src/env_15.0/src/OCA/geospatial' because it doesn't contain any odoo module.
Using a commit message to trigger the build does not work when merging a
PR because last commit is the merge commit and not the commit edited
with the right name.
Given that, the jobs that will run, are defined at the creation of the
pipeline, publishing and creating a release cannot be done based on the
sate of the code.
A way to trigger publication and release is the git tags.
So with theses changes:
- linting is done only on a merge request
- testing and building are performed on a merge request and on the main
branch
When a tag is pushed:
- check are done to ensure that the tag is the same as the version of
the program, in order to not publish and release someting that is not
coherent.
- the program is published on pypi.
- a release is created, but only if the tag is for a major, minor or
patch version. No release created for an alpha, beta or pre-release
version.
So all versions of the program are published on PyPI, but only the
important ones are published via the release mechanism. Because the
release mechanism will warn user for a new version. Version that are not
major, minor or patch are not intended to be used by end users.
The idea of auto publishing and releasing every time a commit is pushed
on the main branch does not work with semantic versioning. For doing
that maybe a calversioning will be better.
The idea of using the CI to push a tag for a new release lead to
security risk. Because the CI will contains credential for writing to
the repository, any contributor can read this token by editing the
gitlab-ci file and use token for bad purposes. Gitlab does not provide
token for writing to a repository owned by the project.
So for now, we control the publication and release of a new version with
two actions:
- updating the version on the pyproject.toml file.
- creating a tag with the same version as in the pyproject.toml file.
Previous syntax does not replace correctly the markers in the string.
Using an f-string fix this.
Before:
2024-02-06 10:47:02.303 | WARNING | odoo_openupgrade_wizard.tools.tools_odoo_module:get_odoo_apps_url:359 - Error when trying to get %s: %s
After:
2024-02-07 10:51:11.964 | WARNING | odoo_openupgrade_wizard.tools.tools_odoo_module:get_odoo_apps_url:356 - Error when trying to get https://apps.odoo.com/apps/modules/12.0/partner_contact_address/: Exceeded 30 redirects.
Cortesy @maisim.
This commit allow to use docker-in-docker to run tests.
Also it will run the tests on python version defined in the
PYTHON_VERSION array. The tox.ini file is not needed anymore.
Test locally can be run on the user python version, and check against
several python version will be done by the CI.
Notice the ODOO_RPC_URL environment variable which allow to mock the RPC
request to the right url.
This tests needs to be run on custom privileged runner.
! Using gitlab runner does not work !
The linting check can be done on any docker image with the latest python
version.
This updates de pre-commit checks and fix file linting to conform to new
standards.
root user should not be used to create container and oow should not be
run as root.
But when running oow in a docker, then the default user of this docker
can be root.
This fix allow to link the odoo user in the odoo environment docker to
match a root user of the host docker.
