Default python images are based on debian and are heavy (~1Go).
Using alpine version for smaller images (~100Mo).
This will save space on the runner and allow more container to be run at
same time.
allow to provide a config file and a modules file option to use
different files than the default ones. this is useful when using the
same environment for different databases.
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.
