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.
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.
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.
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.
