[Qbs] Qbs vs Jenkins

resurrection at centrum.cz resurrection at centrum.cz
Wed Sep 26 06:58:45 CEST 2018

I certainly don't want to reinvent the whole CI system. The Qbs can handle pretty much anything except one thing - its own bootstrapping. By that I mean how would you trigger a Qbs build on a remote server? The Jenkins comes with a server of its own that you can notify, trigger and get info from using simple REST API. It handles the build agents, has web front end for managing those etc. The Qbs has no server obviously so one would need to either use some kind CI system like Jenkins to bootstrap the Qbs based CI build.
But certainly, from experience I would definitely prefer to make these things in QML/JS over YAML/Groovy/Gradle whatever I had to use in different CI systems. Hence the original question. :-)
> Od: "Richard Weickelt" <richard at weickelt.de>
> Komu: qbs at qt-project.org
> Datum: 25.09.2018 23:56
> Předmět: Re: [Qbs] Qbs vs Jenkins
> I am wondering if it was possible to replace the Jenkins pipeline with only Qbs. In theory I see no reason why this should not work given the flexibility of the Qbs but is there any specific functionality out of the box that could make the typicial tasks performed by Jenkins easier? Specifically:
 > * Download sources from Bitbucket (Git)
 > * Running the build using MSBuild .proj file
 > * Publishing the build artifacts to external server
 > All of it can obviously be performed by using Javascript/Commands/Custom rules in Qbs but maybe some of it is already there so I would not need to reinvent the wheel. Also there is a question of bootstrapping such a build system since Jenkins server does have web-based front-end. But I guess it can even be used through it with Jenkins simply running the Qbs. Or perhaps it is a silly idea since Qbs was not meant to be used this way?
 I am interested in this topic as well.
 * What do you mean by "question of bootstrapping such a build system since
  Jenkins server does have web-based front-end"?
 * Do you want to replace Jenkins completely with Qbs?
 * In bigger projects you will most likely have dependencies on other
  projects. You don't want to reinvent package management, do you.
  Conan + Artifactory is used a lot for that purpose. Conan and Qbs are
  good friends. [1]
 In general, I think that a declarative DSL somehow similar to the Qbs' QML
 dialect would be very nice for describing continuous delivery pipelines.
 Especially the Depends and Export item pair would provide a side-effect free
 way to forward data from one job to another and would allow proper
 parallelization of jobs. There could be more QML items, for instance, to
 span a parameter matrix on multiple jobs. Many CI services use yaml these
 days, but my personal impression is that yaml is much harder to read, to
 write and to rehearse than QML.
 [1] https://docs.conan.io/en/latest/reference/generators/qbs.html#qbs-generator <https://docs.conan.io/en/latest/reference/generators/qbs.html#qbs-generator>
 Qbs mailing list
 Qbs at qt-project.org
 http://lists.qt-project.org/mailman/listinfo/qbs <http://lists.qt-project.org/mailman/listinfo/qbs>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qbs/attachments/20180926/0570295a/attachment.html>

More information about the Qbs mailing list