On 02/21/2018 09:02 PM, Tim Ruehsen wrote: > Am Mittwoch, den 21.02.2018, 20:38 +0100 schrieb Christian Grothoff: >> On 02/21/2018 12:15 PM, Tim Rühsen wrote: >>>> Generally, I would like >>>> to end up with a setup where the entire CI configuration is also >>>> in a >>>> Git repo and can be easily collaboratively improved. So if you >>>> have time >>>> and energy to make that happen, great ;-) >>> >>> Gitlab allows exactly that, but you have your own CI already >>> running >>> and the missing parts are maybe just a piece of configuration. >>> So it has to be your initiative. >>> >>> If you like to give Gitlab a chance, let me know and I surely can >>> help. >>> You can also have your own Gitlab instance without gitlab.com >>> involved. >>> And BTW, you can use gitlab-ci-multi-runner to use your own >>> machines / >>> OSes as CI runners. The gitlab.com CI hosting is limited to docker, >>> but >>> hey - it's free to use. And since the CI setup is developed in a >>> git >>> repo as well, nothing is lost, even if gitlab.com dies. >> >> Well, as long as we can easily export the result from gitlab.com to >> eventually move it to independent infrastructure, there's nothing >> wrong >> with starting a CI system there first. So please do give it a shot! >> >> Would it be useful to create a new mailinglist for CI notifications >> for >> this, or should we just use this list? > > I will create a new group on gitlab.com for libmicrohttpd and give you > and Evgeny (?) full premissions (owner). Then it needs one project for > the ci-runners to build and another one for libmicrohttpd. I can set > all this up tomorrow. > Maybe we talk via phone when set up, makes some things easier to > explain. I will give you my phone number then via PM.
Hi, the projects on gitlab.com are set up and public. The project for building/maintaining docker images as CI runners is at https://gitlab.com/libmicrohttpd/build-images. The second is https://gitlab.com/libmicrohttpd/libmicrohttpd. Whenever you push to this repo the CI is triggered, for any branch - as long as it contains .gitlab-ci.yml. You should get a gitlab account and request access or just let me know and I make you the owner (Christian). You should add a public ssh key so you can have write access without usign a password. Once you have write access, you add the repo as remote (example): git remote add gitlab g...@gitlab.com:libmicrohttpd/libmicrohttpd.git git fetch gitlab (and later) git push gitlab I created branch 'ci-test' with that yml file to define three parallel CI runners: gcc, clang+sanitizers and clang-scan. But you can of course add as many as you want. You can see the current status at https://gitlab.com/libmicrohttpd/libmicrohttpd/pipelines. Current status is failure (click on the 'failed' button to see how each job ended). The gcc runner failed because: FAIL: test_quiesce ../../test-driver: line 107: 16501 Aborted (core dumped) "$@" > $log_file 2>&1 The scan-build runner found 19 bugs in the source code, see https://libmicrohttpd.gitlab.io/-/libmicrohttpd/-/jobs/53882904/artifacts/scan-build/2018-02-22-151236-6248-1/index.html The sanitizer runner failed because FAIL: test_upgrade FAIL: test_upgrade_tls You can 'browse' the artifacts (defined in the yml file) and download/view the log files. You'll see memory leaks and two UBSAN failures. Happy bug hunting ! With Best Regards, Tim
signature.asc
Description: OpenPGP digital signature
