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 [email protected].
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.

Reply via email to