Hi, gitlab now allows mirroring projects so I've setup a mirror of nettle at gitlab main server: https://gitlab.com/gnutls/nettle
This has the advantage of using gnutls' CI servers. For that I attach the file needed to be present to enable using these servers.
On every commit nettle will be tested for building + make check, in the available platforms and a mail will be sent to the author/committer.
An example run can be seen at: https://gitlab.com/gnutls/nettle/builds?scope=finished
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
This has the advantage of using gnutls' CI servers. For that I attach the file needed to be present to enable using these servers.
Sounds useful! Can you explain very briefly how that's organized, what's done at your servers, and what's done by gitlab? We should try to avoid "service-as-a-software-substitute"?
Is it easy to add additional configurations? On my wishlist would be x86-64 --disable-assembler, mini-gmp configs, ARM configs, and some big-endian config (not sure what big-endian archs still are relevant and available, possibly mips?).
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml new file mode 100644 index 0000000..816cf74 --- /dev/null +++ b/.gitlab-ci.yml @@ -0,0 +1,16 @@ +Build and Check (x86-64):
Is there any way to get a comment into this file, pointing to relevant documentation? I guess the "tags" are used to select what each build machine does?
- script:
- git submodule update --init && autoreconf -fvi &&
./.bootstrap is nettle's advertised method to generate files needed pre-configure. So I think it's better to use that than autoreconf.
Why submodule, is nettle used as a submodule of gnutls, or is it some magic for the continuous integration system?
Regards, /Niels
On Mon, Dec 21, 2015 at 11:25 AM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
This has the advantage of using gnutls' CI servers. For that I attach the file needed to be present to enable using these servers.
Sounds useful! Can you explain very briefly how that's organized, what's done at your servers, and what's done by gitlab? We should try to avoid "service-as-a-software-substitute"?
My understanding is that you could also do the same by upgrading gitlab in lysator. The gitlab ci setup requires to setup runner systems which will run the assigned tasks. The runner systems run the gitlab-ci-runner software. The gitlab server distributes the builds to runners based on the provided tags. That feature is very new, more info at: https://about.gitlab.com/gitlab-ci/
The runner systems I've setup are 2 Fedora 23 (x86 and x86-64) and a centos7 (x86-64). There are provided by redhat. I had also a via x86 system with debian but it is too slow to build and I have occasionally filesystem corruptions, so I plan to remove it. The available runners are listed at: https://gitlab.com/gnutls/gnutls/runners
Is it easy to add additional configurations? On my wishlist would be x86-64 --disable-assembler, mini-gmp configs,
You can add more options, but note that the more options the more load to the runner systems (shouldn't be much of a problem since nettle builds quite fast). You can see gnutls' file for ideas and the tags in the systems I have setup: https://gitlab.com/gnutls/gnutls/blob/master/.gitlab-ci.yml
If we share the builders I should try to document the available tags better so we can replace/add builders more easy.
ARM configs, and some big-endian config (not sure what big-endian archs still are relevant and available, possibly mips?).
I don't have access to a non-x86 arch which can be used as a builder. If you have we could add it to the pool.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml new file mode 100644 index 0000000..816cf74 --- /dev/null +++ b/.gitlab-ci.yml @@ -0,0 +1,16 @@ +Build and Check (x86-64):
Is there any way to get a comment into this file, pointing to relevant documentation? I guess the "tags" are used to select what each build machine does?
It is documented at: http://doc.gitlab.com/ce/ci/yaml/README.html
- script:
- git submodule update --init && autoreconf -fvi &&
./.bootstrap is nettle's advertised method to generate files needed pre-configure. So I think it's better to use that than autoreconf.
Why submodule, is nettle used as a submodule of gnutls, or is it some magic for the continuous integration system?
Seems like a copy paste thing from the gnutls file. I suggest that you setup the configurations that you like and send me to test.
I noticed that the runners I have don't have the software required to build the documentation. For that I'll need to install that software and introduce a new tag in the runners that have it. That I can do after new year.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
My understanding is that you could also do the same by upgrading gitlab in lysator.
Cool. I'll hear if there's any interest there.
I don't have access to a non-x86 arch which can be used as a builder. If you have we could add it to the pool.
I can't do that at the moment, but it would be nice to have. Either real hardware or emulated.
I noticed that the runners I have don't have the software required to build the documentation. For that I'll need to install that software and introduce a new tag in the runners that have it. That I can do after new year.
I'm not quite satisfied with --disable-documentation. It would be better with configure tests to detect automatically which output formats (if any) are supported on the system.
Regards, /Niels
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
On Mon, Dec 21, 2015 at 11:25 AM, Niels Möller nisse@lysator.liu.se wrote:
- script:
- git submodule update --init && autoreconf -fvi &&
./.bootstrap is nettle's advertised method to generate files needed pre-configure. So I think it's better to use that than autoreconf.
Why submodule, is nettle used as a submodule of gnutls, or is it some magic for the continuous integration system?
Seems like a copy paste thing from the gnutls file. I suggest that you setup the configurations that you like and send me to test.
Sorry for the late reply. I think this could be quite useful.
Do you think this file looks ok? Is there any easy way to test before checking it in?
-----8<--------- Build and Check (x86-64): script: - git pull && ./.bootstrap && ./configure --disable-documentation && make -j4 && make check -j4 tags: - x86-64 except: - tags Build and Check (x86): script: - git pull && ./.bootstrap && ./configure --disable-documentation && make -j4 && make check -j4 tags: - x86 except: - tags -----8<---------
I don't quite understand the details, e.g, environment in which the script is run. If it's in a fresh git checkout, I guess git pull can be omitted?
Regards, /Niels
I tested it and it works (you need to remove the git pull step as this is already done by gitlab ci).
regards, Nikos
On Wed, Jan 20, 2016 at 8:13 PM, Niels Möller nisse@lysator.liu.se wrote:
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
On Mon, Dec 21, 2015 at 11:25 AM, Niels Möller nisse@lysator.liu.se wrote:
- script:
- git submodule update --init && autoreconf -fvi &&
./.bootstrap is nettle's advertised method to generate files needed pre-configure. So I think it's better to use that than autoreconf.
Why submodule, is nettle used as a submodule of gnutls, or is it some magic for the continuous integration system?
Seems like a copy paste thing from the gnutls file. I suggest that you setup the configurations that you like and send me to test.
Sorry for the late reply. I think this could be quite useful.
Do you think this file looks ok? Is there any easy way to test before checking it in?
-----8<--------- Build and Check (x86-64): script:
- git pull && ./.bootstrap && ./configure --disable-documentation && make -j4 && make check -j4
tags:
- x86-64
except:
- tags
Build and Check (x86): script:
- git pull && ./.bootstrap && ./configure --disable-documentation && make -j4 && make check -j4
tags:
- x86
except:
- tags
-----8<---------
I don't quite understand the details, e.g, environment in which the script is run. If it's in a fresh git checkout, I guess git pull can be omitted?
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I tested it and it works (you need to remove the git pull step as this is already done by gitlab ci).
Ok, deleted the git pull commands, and checked in now.
Regards, /Niels
On Thu, Jan 21, 2016 at 8:53 PM, Niels Möller nisse@lysator.liu.se wrote:
I tested it and it works (you need to remove the git pull step as this is already done by gitlab ci).
Ok, deleted the git pull commands, and checked in now.
Nice. I do not see new builds being spawned but this seems related to an issue gitlab guys had with mirrored project builds [0]. I hope that this is resolved soon.
regards, Nikos
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se