JENKINS-27295 discusses getting values from various kinds of parameters. Handling FileParameterValue is another matter. buildEnvironment (what is called today) is useless since it gives only a file name. createBuildWrapper is the way this works in a freestyle project, but this cannot work in a workflow; even if it were to return a SimpleBuildWrapper (JENKINS-24673) it is not clear where that would be called, since we can only use it from a workspace. getValue as currently implemented is useless since a FileItem does not have whitelisted methods, and anyway we would not want the flow itself to be copying streams to the workspace; this needs to be done by infrastructure. The only way forward I can see at the moment is for getValue to return a SimpleBuildWrapper, so that your flow could read

      node {
        wrap([$delegate: parameters.myFileParam]) {
          sh 'cat myFileParam'
        }
      }
      

          [JENKINS-27413] Handle file parameters

          I don't quite understand if this is just not implemented yet, or if it's impossible to implement at all. If it is possible, we might be able to fund the development of this feature, as we need it too. As I am still rather new to the Jenkins community: Can anyone recommend me any companies that could do that?

           

          Andreas Schmid added a comment - I don't quite understand if this is just not implemented yet, or if it's impossible to implement at all. If it is possible, we might be able to fund the development of this feature, as we need it too. As I am still rather new to the Jenkins community: Can anyone recommend me any companies that could do that?  

          Jesse Glick added a comment -

          schmandr as to technical design, see my comments of 2018-10-24 and 2019-06-21. I am interpreting the requirement more broadly than the original statement: a user or script should be able to trigger a Pipeline job with a build parameter that includes the contents of a (possibly large, possibly binary, but not secret) file, using any common mechanism (GUI, HTTP POST, build-job CLI command, build step), in such a way that some convenient (Scripted and/or Declarative) syntax may be used to retrieve that file in a designated workspace location at a designated time, including in future rebuilds.

          Jesse Glick added a comment - schmandr as to technical design, see my comments of 2018-10-24 and 2019-06-21. I am interpreting the requirement more broadly than the original statement: a user or script should be able to trigger a Pipeline job with a build parameter that includes the contents of a (possibly large, possibly binary, but not secret) file, using any common mechanism (GUI, HTTP POST, build-job CLI command, build step), in such a way that some convenient (Scripted and/or Declarative) syntax may be used to retrieve that file in a designated workspace location at a designated time, including in future rebuilds.

          Jesse Glick added a comment -

          Jesse Glick added a comment - Prototyping in: https://github.com/jglick/alt-file-parameter-plugin

          Liam Newman added a comment -

          Liam Newman added a comment - jglick Still prototyping? Now in https://github.com/jenkinsci/file-parameters-plugin

          Jesse Glick added a comment -

          bitwiseman the basics work fine. I (or somebody) need to do a bit more testing, and work on design of usage from the input and build steps (or a decision that integration with these steps will not be supported). On my back burner.

          Jesse Glick added a comment - bitwiseman the basics work fine. I (or somebody) need to do a bit more testing, and work on design of usage from the input and build steps (or a decision that integration with these steps will not be supported). On my back burner.

          Jesse Glick added a comment -

          I have released an initial version of the File Parameter plugin. I think it covers the basic use cases for Pipeline users. Use its issue tracker as needed.

          Jesse Glick added a comment - I have released an initial version of the File Parameter plugin. I think it covers the basic use cases for Pipeline users. Use its issue tracker as needed.

          David Navrkal added a comment - - edited

          Hello jglick, first of all, thx for implementing new plugin! Is there any change your File Parameter plugin will get promoted to the Cloudbees Update Center where are verified and trusted opensource plugins since it is currently only working workaround for broken file parameter?

          As well I guess if this issue was closed with resolution people should use new File Parameter plugin then the original (for years broken and still not working) file parameter should be removed from Jenkins to prevent people confusion and stop waisting time on not existing workarounds...

          David Navrkal added a comment - - edited Hello jglick , first of all, thx for implementing new plugin! Is there any change your File Parameter plugin will get promoted to the Cloudbees Update Center where are verified and trusted opensource plugins since it is currently only working workaround for broken file parameter? As well I guess if this issue was closed with resolution people should use new  File Parameter plugin then the original (for years broken and still not working) file parameter should be removed from Jenkins to prevent people confusion and stop waisting time on not existing workarounds...

          Jesse Glick added a comment -

          Is there any change your File Parameter plugin will get promoted to the Cloudbees Update Center

          If you are a CloudBees customer, open an RFE via the normal process. I am not personally in charge of such decisions.

          the original […] file parameter should be removed from Jenkins [core]

          Well, I do not think we can remove it. In principle it could be detached to a (deprecated) plugin. Certainly we could consider adding help text and the like in core suggesting use of https://plugins.jenkins.io/file-parameters/ in its place, once it has gotten some more serious usage to shake out design problems.

          Jesse Glick added a comment - Is there any change your File Parameter plugin will get promoted to the Cloudbees Update Center If you are a CloudBees customer, open an RFE via the normal process. I am not personally in charge of such decisions. the original […] file parameter should be removed from Jenkins [core] Well, I do not think we can remove it. In principle it could be detached to a (deprecated) plugin. Certainly we could consider adding help text and the like in core suggesting use of https://plugins.jenkins.io/file-parameters/ in its place, once it has gotten some more serious usage to shake out design problems.

          Rene Buergel added a comment - - edited

          jglick this is a cool plugin, thank you!

          how's the intended handling of non-mandatory large files used with stashedFile in declarative?

          • If no file is provided and the build is triggered manually, unstashing works, but the file is 0 Bytes.
            For stages depending on the file, I'm using the following (unfortunately platform-dependent) when-condition:
            when { expression { sh(returnStatus:true, script: '[ -s FPGA.zip ]' ) == 0 } }
            
          • If no file is provided and the build is triggered by the SCM, unstashing fails because the whole parameter seems to be missing, so I need to wrap the unstash into a catchError

          I think, that's a quite cumbersome error handling for basically the same case (no file provided)

          Rene Buergel added a comment - - edited jglick this is a cool plugin, thank you! how's the intended handling of non-mandatory large files used with stashedFile in declarative? If no file is provided and the build is triggered manually, unstashing works, but the file is 0 Bytes. For stages depending on the file, I'm using the following (unfortunately platform-dependent) when-condition: when { expression { sh(returnStatus: true , script: '[ -s FPGA.zip ]' ) == 0 } } If no file is provided and the build is triggered by the SCM, unstashing fails because the whole parameter seems to be missing, so I need to wrap the unstash into a catchError I think, that's a quite cumbersome error handling for basically the same case (no file provided)

          Jesse Glick added a comment -

          reneb for any bugs or RFEs please use GitHub Issues, and be sure to provide a complete, self-contained, reproducible test case.

          Jesse Glick added a comment - reneb for any bugs or RFEs please use GitHub Issues, and be sure to provide a complete, self-contained, reproducible test case.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            111 Vote for this issue
            Watchers:
            119 Start watching this issue

              Created:
              Updated:
              Resolved: