That sounds like a promising approach. I will go investigate that On Saturday, 9 April 2016 01:16:58 UTC+12, Martin d'Anjou wrote: > > You could look at the Simple Build For Pipeline Plugin > <https://github.com/jenkinsci/simple-build-for-pipeline-plugin>, combined > with some TBD way of automatically creating job configurations (perhaps > something like the BitBucket Branch Source Plugin > <https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+Branch+Source+Plugin>). > > The Simple Build For Pipeline has a base class that can be expanded to > support a custom mini-DSL code job declaration, and implement a Pipeline > DSL flow inside a plugin of your own writing. With that plugin, users are > presented with a high level declarative view of their flow, so they can > turn knobs on their flow. This declarative view could be stored in their > source code repo (git) as a "Jenkinsfile". The BitBucket Branch Source > Plugin can scan BitBucket repositories and create jobs for projects that > contain a special file literally named the "Jenkinsfile" (optionally one > job per branch, even one job per pull-request if you wish). This > Jenkinsfile could contain the call to the extension of Simple Build. The > extension of Simple Build has to be a plugin that is uploaded to Jenkins. > It provides many advantages: it can be unit tested as a Jenkins plugin on > the command line (mvn test), and the flow becomes available as global > variable in Jenkins (thus making it available to any job configuration in > Jenkins). Conceptually, you could have multiple custom Simple Build > extensions (each one as a different plugin of your own, or many in the same > plugin of your own): one per type of job you need to run. > > Conceptually, that is the closest I have come to being able to test the > job configurations before I deploy them, the closest I have come to give > users the ability tweak their build parameters in their own source code > without making everyone an administrator. But I am still lacking the > ability to create multiple jobs per project (i.e. multiple Jenkins jobs for > each user (git) repository). Unfortunately, there can only be one > Jenkingfile per branch, I wish I could have many since I don't want my > pipeline all in the same job config. > > Conceptually, if the Simple Build plugin extension is kept backwards > compatible (which should be doable with good enough unit tests on the > custom plugin), rerunning older builds, even years later, should be > possible. > > It is still a work in progress for me. > > Hope this helps, > Martin > > On Wednesday, March 9, 2016 at 11:04:13 PM UTC-5, Patrick van der Velde > wrote: >> >> Hi All >> >> We are trying to improve our build server setup and are trying to solve >> the problem that users can change the configuration of their builds through >> the UI, but those changes are not stored in source control, so it is hard >> to determine what has changed and who made those changes. Additionally (and >> maybe even more importantly) it is hard to rebuild an old version of the >> software because that may require a different job configuration. I know >> there are several plugins to handle backing up configuration changes to VCS >> / etc. but those backup to their own repositories (if they work) and we >> want the configuration for a build job to be stored with the source code >> for that build job, not in a separate repository. Because if we store the >> definition for the build job and the source code in the same location we >> could easily recreate a build environment as it was for that specific >> commit. >> >> One option would be to use the Job-DSL plugin to create the jobs from a >> configuration file that is in VCS. The only catch with that would be that >> editing the configuration would require users to update the configuration >> text file which I suspect would increase the chance of errors and also >> makes it harder for the users to test configuration changes. Ideally we >> would like to keep the UI as the way to edit configurations but then just >> have that write to the configuration file. >> >> I suspect this problem cannot be solved with our current version of >> jenkins (latest LTS 1.642.2) but I'm wondering if there are any plugins / >> combination of plugins / other apps that could make this possible? >> >> thanks >> >> Petrik >> >
-- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/538efdfd-a2aa-4a0b-b92f-0746b83466bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
