| Message ID | 20210426071749.26921-1-michael.adler@siemens.com |
|---|---|
| Headers | show |
| Series | Modularize CI and support for Gitlab | expand |
Hi Michael, On 26.04.21 09:17, Michael Adler wrote: > Hi all, > > the primary goal of this patch series is to make it easier to run the SWUpdate test suite locally. > > Previously, I had to extract the shell commands from travis.yml and add some missing dependencies (which are part of the > Travis-flavored Ubuntu image, but not part of Ubuntu's official Docker image) in order to run the tests inside > a container. > > Now it is as easy as spawning an instance of the official Ubuntu Focal Docker image and running the commands: > > 1) ./ci/setup.sh > 2) ./ci/install-src-deps.sh > 3) ./ci/test-configs.sh > > Further, having the code outside of travis.yml eliminates CI vendor lock-in, e.g. adding support for Gitlab CI is now > trivial, which I have done in the second patch. This means if you fork the project into Gitlab (e.g. for preparing > an upstream patch series), you will automatically benefit from free CI. I won't change the official repo for the project else I will be hit by many angry users, but there is already a mirror on a Gitlab instance here: https://source.denx.de/swupdate/swupdate It is automatically syncronized with github and can be used for Gitlab runners. Best regards, Stefano Babic > > Kind regards, > Michael > > Michael Adler (2): > CI: Modularize Travis configuration > CI: Added config for Gitlab > > .gitignore | 3 ++ > .gitlab-ci.yml | 10 +++++++ > .travis.yml | 65 +++--------------------------------------- > ci/install-src-deps.sh | 59 ++++++++++++++++++++++++++++++++++++++ > ci/setup.sh | 55 +++++++++++++++++++++++++++++++++++ > ci/test-configs.sh | 18 ++++++++++++ > 6 files changed, 149 insertions(+), 61 deletions(-) > create mode 100644 .gitlab-ci.yml > create mode 100755 ci/install-src-deps.sh > create mode 100755 ci/setup.sh > create mode 100755 ci/test-configs.sh >
Hi Stefano, > I won't change the official repo for the project else I will be hit by many > angry users which change are you refering to? Extracting the shell script from travis-ci.yml is mostly a refactoring, i.e. it (should) not modify existing behavior. In fact, it also addresses a shortcoming in the scripts, i.e. it adds some missing dependencies which are part of the the Travis image but _not_ part of the official Ubuntu Docker image. > It is automatically syncronized with github and can be used for Gitlab > runners. How does that help when there is no gitlab-ci.yaml in the project? I can understand if you don't want to add the gitlab-ci patch, but the first patch has nothing to do with Gitlab and helps a lot for running the tests locally, so I believe it is useful for everybody - or at the very least, does not hurt anyone :) Kind Regards, Michael
Hi Michael, we are misunderstanding. On 26.04.21 11:08, Michael Adler wrote: > Hi Stefano, > >> I won't change the official repo for the project else I will be hit by many >> angry users > > which change are you refering to? I just said that the official repo for the project will remain on Github, but mirrors can be se on Gitlab instances. I am not refering to your scripts. > Extracting the shell script from travis-ci.yml is mostly a refactoring, i.e. it > (should) not modify existing behavior. In fact, it also addresses a shortcoming in the scripts, i.e. it adds some > missing dependencies which are part of the the Travis image but _not_ part of the official Ubuntu Docker image. > >> It is automatically syncronized with github and can be used for Gitlab >> runners. > > How does that help when there is no gitlab-ci.yaml in the project? Until the project is not hosted on a gitlab instance, there is no need. But hosting it on a mirror can open to use Gitlab's CI as well. > I can understand if you don't want to add the > gitlab-ci patch, Never said this. > but the first patch has nothing to do with Gitlab And never said something against inclusion your series. > and helps a lot for running the tests locally, so > I believe it is useful for everybody - or at the very least, does not hurt anyone :) > Best regards, Stefano Babic
Hi Stefano, > we are misunderstanding. yes indeed, sorry for that. > I just said that the official repo for the project will remain on Github, totally agree, I never meant to host SWUpdate anywhere else. I merely wanted to add an additional CI configuration as a 'goodie' for people who fork SWUpdate (for whatever reason) on a Gitlab instance - or to simply demonstrate that adding another CI provider is fairly easy with the changes from my first patch. (This is a topic for another discussion, but it might be worth pointing out that e.g. Cirrus CI offer support for testing under FreeBSD - which is also supported by SWUpdate but AFAIK not CI tested.) > And never said something against inclusion your series. alright then, looking forward to your feedback :) Kind Regards, Michael [1] https://cirrus-ci.org/features/#comparison-with-popular-ciaas