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" <rich...@weickelt.de>
Komu: qbs@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.
Richard
[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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
<http://lists.qt-project.org/mailman/listinfo/qbs>
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
