A good support for automatic generaded badges came out to be more complicated than expected (you can read about the reasons in detail [HERE](https://gitlab.com/gitlab-org/gitlab-ce/issues/50603)), but the final solution seems to be nice and good working. This solution requires an Access Token with api access to the projects repository. This Access Token can be created by any user with permissions to create/read/write/delete new branches of the projects repository.
Access Tokens can be created in the GitLab´s profile settings of that user: Settings->Access Tokens->Scopes "api".
To ensure, that the Access Tokens are not readable by everyone who has access to the GitLab repository,
the Access Tokens need to be protected and not stored in any repository file. Instead of Git, GitLab can store the Access Token at a protected place, which is only readable to users with maintainer-permissions. Therefore, create a new Access Token and store it in Project->Settings->CI/CD->Variables as **Protected Variable**. For this project the variable name of the token is CI_BADGE_TOKEN.
| **Note:** Inside the .gitlab-ci.yml file the protected variables are available for the CI Scripts ([EXAMPLE](https://gitlab.version.fz-juelich.de/vis/jusense-cicd/blob/master/.gitlab-ci.yml#L80)).|
Badges are generated with [anybadge](https://pypi.org/project/anybadge/) by the [THIS bash function](https://gitlab.version.fz-juelich.de/vis/jusense-cicd/blob/master/ci/ci_funcs.sh#L3). It is stored in a temporary branch with the name tmp_\<PIPELINE_NAME\>, which is deleted when the execution of the CI pipeline has finished. Before, the generated badges of all CI Jobs are copied by the last CI Job "pages" to the artifact "pages".
The drawback of this approach is, that you need to have an Access Token, which is readable to all maintainers of the project. And that the creation and deletion of a tmp branch will leave a lot of "noice" at the projects ["Activity" page](https://gitlab.version.fz-juelich.de/vis/jusense-cicd/activity). Alternative approaches are discussed [HERE](https://gitlab.com/gitlab-org/gitlab-ce/issues/50603).
A good support for automatic generaded badges came out to be more complicated than expected (you can read about the reasons in detail [HERE](https://gitlab.com/gitlab-org/gitlab-ce/issues/50603)), but the final solution seems to be nice and good working.
Badges are generated with [anybadge](https://pypi.org/project/anybadge/) by the [THIS bash function](https://gitlab.version.fz-juelich.de/vis/jusense-cicd/blob/master/ci/ci_funcs.sh#L3). The generated badges of all CI Jobs are copied by the last CI Job "pages" to the artifact "pages".
The drawback of this approach is, that one a single Artifacts section is allowed in .gitlab-ce.yml. And this needs to be 'pages' in this case. All CI Jobs must share the same Artifacts. And one should better know the exact behaviour of Artifacts in GitLab:
Artifacts are ...
* ... a list of files and directories
* ... available for subsequent(!) jobs of the same run
* --- before job start ---
* ... passed and extracted by default from all previous stages (this can be more than defined in 'paths')
* ... only passed between different jobs of the same stage, if the previous job is a dependency of the later (!!)
* --- on job end ---
* ... appended(!) by the files and directores defined in artifacts paths
* ... sent to GitLab after the job finishes
* ... saved on the GitLab server as a zip file.
* ... attached to a job after it completes
The artifact "pages" is published online by [GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/). Therefore, for all CI Jobs a fixed URL is available to the latest generated badge.
An example URL is: http://vis.pages.jsc.fz-juelich.de/jusense-cicd/badges/badge_build-openmpi_%{default_branch}.svg
