Hi all,
With the help for Fred during EclipseCon Europe, we now have a Jenkinsfile in the aCute repository and can use it to build and publish the content of the "master" branch. That's a cool experiment.
However, I have a few questions/concerns about those files:
1. The DSL is kind of horrible. In the end, it seems like if you need to code a lot of Groovy logic wrapped in a unfriendly DSL with relatively poor tools. It's not much maintainable in my opinion.
2. In the end, it seems like one Jenkinsfile is only one build, whereas a typical Eclipse project would have multiple builds (Gerrit, SonarQube, various branches...). While the various branches case seems to be very well supported by Jenkins and Jenkinsfile natively, the "variants" (Gerrit, SonarQube, IT-Tests, you name it) which are more usually triggered on a schedule with some additional steps or different settings cannot be easily supported.
In the end, I have the impression Jenkinsfile as they are now are overkill and do not match our use-cases.
So I'm wondering what could be an alternative.
And I can suggest one, that maybe Jenkins has some support for:
for JBoss Tools, we used to export the config.xml files (build descriptions) from Jenkins and commit them in some repo.
Would it be possible, instead of using Jenkins file, to have a JIPP able to read those config.xml files from the repo and to provision/update the jobs accordingly? In such case, for aCute, we could have 3 config.xml files in some "jenkins" folder and let whichever Jenkins instance being populated with those.
WDYT?
