Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43758

Parameters disappear from pipeline job after running the job

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: job-dsl-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.53,
      Build Pipeline Plugin 1.5.6
      Pipeline
    • Similar Issues:

      Description

       

       

       

      Steps to reproduce

      1. I have created Pipeline job
      2. During creation I checked up "This project is parameterized" checkbox and added two Choice parameters
      3. I have run the job and it failed
      4. I checked the configuration of the job and parameters are no longer there and "This project is parameterized"  checkbox is no longer checked up.

        Attachments

          Issue Links

            Activity

            Hide
            famod Falko Modler added a comment -

            Annother super annoyed user here (sorry to say that, but that's just the truth).
            We are setting up most of our jobs via JCasC (which wraps JobDSL) and every single time we execute our JCasC yaml files, all properties that are defined by the respective pipeline scripts are lost: parameters, triggers, sidebar links etc.
            Losing parameters of jobs that are triggered not by human project members but by other systems/scripts (e.g. Pull Request Notifier for Bitbucket Server) is especially painful.
            Those jobs frequently triggered by human project members will sooner or later re-receive their parameters because someone will just click "Build Now" eventually but those jobs triggered from outside will just never run (rejected because of "unknown" parameters?).
            Every single time we execute our JCasC scripts we have to go through a list of jobs and "fix" them by clicking "Build Now". Yes, we could write a script for that but some jobs don't have parameters.
            Instead they need to have their scm-polling re-initialized. Since some of those jobs run for many hours, so we need to abort them right away. Writing a script for all those cases feels like investing too much time on the wrong end of the problem.

            I am willing to contribute a fix but where to start? What is the right approach? Should we start with an opt-in to preserve (instead of wipe) parameters, triggers etc.?

            Show
            famod Falko Modler added a comment - Annother super annoyed user here (sorry to say that, but that's just the truth). We are setting up most of our jobs via JCasC (which wraps JobDSL) and every single time we execute our JCasC yaml files, all properties that are defined by the respective pipeline scripts are lost: parameters, triggers, sidebar links etc. Losing parameters of jobs that are triggered not by human project members but by other systems/scripts (e.g. Pull Request Notifier for Bitbucket Server) is especially painful. Those jobs frequently triggered by human project members will sooner or later re-receive their parameters because someone will just click "Build Now" eventually but those jobs triggered from outside will just never run (rejected because of "unknown" parameters?). Every single time we execute our JCasC scripts we have to go through a list of jobs and "fix" them by clicking "Build Now". Yes, we could write a script for that but some jobs don't have parameters. Instead they need to have their scm-polling re-initialized. Since some of those jobs run for many hours, so we need to abort them right away. Writing a script for all those cases feels like investing too much time on the wrong end of the problem. I am willing to contribute a fix but where to start? What is the right approach? Should we start with an opt-in to preserve (instead of wipe) parameters, triggers etc.?
            Hide
            abayer Andrew Bayer added a comment -

            So if you're not using Job DSL, please open a separate JIRA. If you're using the properties step in Scripted Pipeline or the parameters directive in Declarative, those do try to preserve job properties and build parameters defined outside of the pipeline, but Job DSL is still going to wipe out whatever is in the properties and parameters when it runs its seed job. Also, don't ever call properties step more than once in a pipeline - you're gonna run into a bunch of potential pitfalls there.

            Show
            abayer Andrew Bayer added a comment - So if you're not using Job DSL, please open a separate JIRA. If you're using the properties step in Scripted Pipeline or the parameters directive in Declarative, those do try to preserve job properties and build parameters defined outside of the pipeline, but Job DSL is still going to wipe out whatever is in the properties and parameters when it runs its seed job. Also, don't ever call properties step more than once in a pipeline - you're gonna run into a bunch of potential pitfalls there.
            Hide
            ss_vinoth22 vinoth SS added a comment -

            Andrew Bayer Any update on this issue? was there any upgrade in the plugin to fix this issue, Or do we need to go with Alexander's Wrokaround? I tried with latest JOB DSL 1.74 plugin as well it is still having the issue. Please do update the roadmap/ fix

            Show
            ss_vinoth22 vinoth SS added a comment - Andrew Bayer Any update on this issue? was there any upgrade in the plugin to fix this issue, Or do we need to go with Alexander's Wrokaround? I tried with latest JOB DSL 1.74 plugin as well it is still having the issue. Please do update the roadmap/ fix
            Hide
            akom Alexander Komarov added a comment - - edited

            Aaron D. Marasco, to my knowledge there is no way to get current job properties in the format suitable for properties{}.   

            The only way I can see of doing this would be to access the individual getters on currentBuild.rawBuild.parent (an instance of WorkflowRun ) and then transform their current values into arguments to properties{}.  This would certainly be brittle, and if you use Script Security, this will require approval.

             

            Show
            akom Alexander Komarov added a comment - - edited Aaron D. Marasco , to my knowledge there is no way to get current job properties in the format suitable for  properties{} .    The only way I can see of doing this would be to access the individual getters on  currentBuild.rawBuild.parent (an instance of WorkflowRun ) and then transform their current values into arguments to  properties{}.   This would certainly be brittle, and if you use Script Security, this will require approval.  
            Hide
            aarondmarasco_vsi Aaron D. Marasco added a comment -

            Just stumbled on this bug as well, wondering why I lose my JobDSL parameters after a run. Alexander Komarov has a great workaround above, but I really need what Michal Rysanek is asking for - a way to get the current properties so I can add to them.

            Show
            aarondmarasco_vsi Aaron D. Marasco added a comment - Just stumbled on this bug as well, wondering why I lose my JobDSL parameters after a run. Alexander Komarov has a great workaround above, but I really need what Michal Rysanek is asking for - a way to get the current properties so I can add to them.

              People

              • Assignee:
                Unassigned
                Reporter:
                dzieciou Maciej Gawinecki
              • Votes:
                19 Vote for this issue
                Watchers:
                23 Start watching this issue

                Dates

                • Created:
                  Updated: