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.
Removing a container can take some time to be performed. Listing
containers when a container is currently being removed may cause errors.
Because listing container and filtering them by name requires to fetch
data from the container that is currently being removed.
Depending of the test environment, the url of the odoo container may
change.
Using pytest in a local shell, Odoo will be available at 0.0.0.0
address.
Using pytest in a docker-in-docker environment, the url for the Odoo
container will be exposed on a different address depending on the
configuration of the docker-in-docker environment.
The mock check whether the user has configured a différent URL for the
Odoo RPC calls, and set it accordingly using mock feature.
In the gitlab-ci, the ODOO_RPC_URL should be used to set the correct
address for the RPC calls.
The lock file is regenerated and some dependencies are updated.
Poetry now uses a system of group for extra dependencies. Dependencies
for testing purposes has been put in the "dev" group in the
pyproject.toml file.
Main new features:
- oow psql: run any query on a database
- oow dumpdb: dump database and its filestore
- Documentation improvement.
Other small fixes.
This will produce the following behaviour:
When a commit with a title like "Bump to version x.y.z" is committed to
main branch (either by merging a merge request or by pushing it directly
to the main branch), a build of the project is triggered and the result
is pushed on PyPI.
Also a release on the github project is created with the version of the
program as title and the content of the commit message as description.
This will help deploying release of oow. It will also warn followers
that a new version is released by a notification if they choose to.
PYPI_USER and PYPI_TOKEN are value set on the gitlab settings of the
project and can only be viewed by maintainers.
In a proper file each line end with a newline character, even the last
one.
Wrong file:
Using `write()` function does not add a newline character at the end of
the write. So writing a string in a file with `write()` leads to a file
like this:
```
line1\n
line2\n
lastline
```
Good file:
Using the `print()` command automatically ends the string with a newline
character. So that we ends with a proper file:
```
line1\n
line2\n
lastline\n
```
Also the with statement automatically closes the file at the end of the
block.