Let\'s say I have configured multiple jobs for a project like following:
build_win32:
script: ...
build_ios:
script: ...
unit_tests:
script: ...
server_
You can achieve what you need by creating badges in your pipeline steps, registering the badge files as pipeline artifacts, and publishing them to GitLab Pages. From there you can reference the badges in your README.md
In each of your CI steps you would need to generate badge files, and store them under public/<badge-file>.svg
You can generate badge files using http://shields.io. I have written my own Python badge generator, which can be found here: https://github.com/jongracecox/anybadge
Register each of the generated badge files as artifacts in the CI job by including this in each job in the .gitlab-ci.yml
:
build_win32:
script: ...
- <generate public/build_win32.svg>
artifacts:
paths:
- public/build_win32.svg
build_ios:
script: ...
- <generate public/build_ios.svg>
artifacts:
paths:
- public/build_ios.svg
unit_tests:
script: ...
- <generate public/unit_tests.svg>
artifacts:
paths:
- public/unit_tests.svg
server_tests:
script: ...
- <generate public/server_tests.svg>
artifacts:
paths:
- public/server_tests.svg
client_tests:
script: ...
- <generate public/client_tests.svg>
artifacts:
paths:
- public/client_tests.svg
Include a new pages
publish step, which deploys everything in the public directory to GitLab pages:
pages:
stage: deploy
artifacts:
paths:
- public
only:
- master
You shouldn't need to modify the above. Once this job runs, all the files in public
will be available via the GitLab pages web server. This is often http://NAMESPACE.GITLABPAGESSERVER/project
Read more about GitLab pages here: https://docs.gitlab.com/ce/user/project/pages/index.html
When the master pipeline runs for the project, the badge files are published to GitLab Pages, and can then be referenced from the project README.md
.
I understand why you would ask this question, but I would like to explain why you might not want to do that.
GitLab pipelines run on every push to the project - on every branch. Typically you would only want to generate badges for your README file from the master
branch (or a release) branch, so you would restrict the pages step to only run on master@group/project.
Also consider that a pipeline will usually be configured to stop when a job errors. This would mean that if a master pipeline job failed then the badges for that pipeline would not get generated, and would therefore not be helpful in determining which job failed.
The best place to get your immediate feedback is in the pipeline view, and you could add the pipeline success badge to your readme with a link to the pipeline, usually something like https://gitlabserver/namespace/project/badges/branch/build.svg
If you still want to use the approach you have described then my suggestion would be to set each pipeline stage to allow failure. This would allow the full pipeline to run, despite failures in any job, and the badges should still get generated, and published to Pages.
You can follow the steps of JGC, but instead of deploying the badge on the public directory of a Gitlab page, you can directly link to the latest build artefact.
For instance, the following URL links to a pylint badge created with anybadge and uploaded as artifact.
https://gitlabserver/namespace/project/-/jobs/artifacts/master/raw/public/pylint.svg?job=test
I developed a workaround solution to real-time per-job badges. It can be easily modified into anything else.
The example repo: ci-test/badges. There is also a complete walkthrough so I won't copy-paste it here.
The core idea is (assuming you're now inside a running CI job):
Dropbox supports calling its API via HTTP requests (see this). Thus, all the above can be done using e.g. curl or Python requests - basic tools. You just need to pass the Dropbox access token as secret variable and save the file under the same name to overwrite the old badge.
Then, you can then directly link the Dropbox badge wherever you need. There are some tricks to it so be sure to check my example repo if you want to use it. For me it works quite well and seems to be fast.
The advantage of this method is that you don't have to mess with GitLab Pages. Instead of publishing on Pages you put it to Dropbox. That is a simple file transfer called by HTTP request. No more to that.
I prefer to use a temporary branch to store badges between different ci-jobs.
You can find a detailed project example, which shows how to use badges per job using a temporary branch with GitLab here: https://gitlab.version.fz-juelich.de/vis/jusense-cicd
And its documentation here: https://gitlab.version.fz-juelich.de/vis/jusense-cicd/wikis/Continuous-Integration-and-Delivery
But, whatever strategy you prefer, custom badges are until now not properly supported in GitLab. Check this issue for more details: have created an issue at GitLab for that: https://gitlab.com/gitlab-org/gitlab-ce/issues/50603