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.
