Re: [Qbs] Qbs vs Jenkins

[resurrection]

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" 
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 

___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs 


___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Qbs vs Jenkins

[Richard Weickelt]

> 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
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs