Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a CI pipeline for pull request #1680

bobcanthelpyou opened this issue Mar 21, 2019 · 4 comments


Copy link

commented Mar 21, 2019

Some Gluon Developers like to have a kind of CI pipeline for pull requests.

  1. What should such a pipeline check for, could help with?
  • Syntax of scripts, code, docs, ...
  • Linting of scripts, code, docs, ...
  • Need something to be updated, language files, target missing in docs, ...
  • ...
  1. And what kind of software should be used?
  • TravisCI
  • self hosted
    • Jenkins
    • ...
  • ...
  1. What rules should apply? What should happen when pipeline fails?
  • just warning/suggestions
  • block merge
  • ...
  1. What else should we think about?
  • only changes and depending stuff should be checked vs. check everything all the time
  • ...

@bobcanthelpyou bobcanthelpyou changed the title Add a CI pipeline for pulll request Add a CI pipeline for pull request Mar 22, 2019


This comment has been minimized.

Copy link

commented Mar 26, 2019

I have a powerful server where I could offer a KVM for CI. @lemoer has written a test setup where Gluon nodes could be virtualized using the x86 images a while ago. I don't know the state of it, but it would be cool if we'd support proper unit tests.


This comment has been minimized.

Copy link

commented Mar 26, 2019

I would not consider it as stable, but it is working: (besides a bug in python3.7 and python3.8 itself)

Feel free to test it.


This comment has been minimized.

Copy link

commented May 25, 2019

I think standardizing the build in some tool would be interesting - then in a second step talking about capacity would be interesting. Building a jenkinsfile that builds gluon inside a prepared docker environment could be of merit. It certainly would stop each community building their own build tool.


This comment has been minimized.

Copy link

commented Aug 8, 2019

I kind of did a first test with Gitlab:

I would like to get some feedback about that.
What kind of architecture/versions/patchsets would make sense?

Due to the Gitlab Runner Architecture, it is quite easy to add new Build Nodes (build time around 3h)

Also unclear - at least to me - is where to store the final Binaries.
Is there a central file repository somewhere for distribution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.