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

archiveArtifacts artifacts: syntax silently ignored

      Syntax for archiving artifacts in the pipeline used to be

       

      archiveArtifacts artifacts: '*/.log'

       

      Now statements like this are simply silently ignored (build does not fail, it just does not do any archiving)

       

      The Pipeline Syntax generator now seems to generate

       

      step archiveArtifacts('*/.log')

       

      Was this an intentional change (basically all pipelines need to be changed to the new way? Shouldn't at the very least the builds fail instead of silently ignoring archiving?

       

      It used to work with LTS 2.73.2 and now fails with LTS 2.73.3

          [JENKINS-48123] archiveArtifacts artifacts: syntax silently ignored

          Mark Waite added a comment -

          tario I believe this bug report is assigned to the wrong project. It is not a Jenkins website bug report. Could you assign it to the correct project?

          The jenkins.io documentation uses an example of the form you described. If there has been a change that the form you described no longer works, I suspect that is an unintentional change.

          Mark Waite added a comment - tario I believe this bug report is assigned to the wrong project. It is not a Jenkins website bug report. Could you assign it to the correct project? The jenkins.io documentation uses an example of the form you described. If there has been a change that the form you described no longer works, I suspect that is an unintentional change.

          Sorry about that, didn't realize there were multiple projects here, it's fixed now.

          Patrick Ruckstuhl added a comment - Sorry about that, didn't realize there were multiple projects here, it's fixed now.

          Daniel Beck added a comment -

          It's unclear what this is about. In the case of a single argument, the two archiveArtifacts invocations should be equivalent. Are you saying they behave differently? Please provide a complete, minimal, sample pipeline script demonstrating the issue.

          Daniel Beck added a comment - It's unclear what this is about. In the case of a single argument, the two archiveArtifacts invocations should be equivalent. Are you saying they behave differently? Please provide a complete, minimal, sample pipeline script demonstrating the issue.

          Patrick Ruckstuhl added a comment - - edited

          Simple pipeline which used to work

          node{
            sh 'echo "foo" > a.log'
            archiveArtifacts artifacts: '*.log'
          }
          
          

          Now runs through green but no artifacts are archived. If I rewrite this into

          node{
            sh 'echo "foo" > a.log'
            step archiveArtifacts('*.log')
          }
          

          It seems to work fine.

          It's not clear why the first version suddenly no longer works. The jenkins website for example lists the syntax from the first pipeline. At the very least if this is no longer supported, the builds would need to fail as in the current state, the builds run through green but silently no longer archive any artefacts.

          Latest LTS Version, all pipeline plugins upgrade to the latest version.

          Patrick Ruckstuhl added a comment - - edited Simple pipeline which used to work node{ sh 'echo "foo" > a.log' archiveArtifacts artifacts: '*.log' } Now runs through green but no artifacts are archived. If I rewrite this into node{ sh 'echo "foo" > a.log' step archiveArtifacts( '*.log' ) } It seems to work fine. It's not clear why the first version suddenly no longer works. The jenkins website for example lists the syntax from the first pipeline. At the very least if this is no longer supported, the builds would need to fail as in the current state, the builds run through green but silently no longer archive any artefacts. Latest LTS Version, all pipeline plugins upgrade to the latest version.

          Mark Waite added a comment -

          danielbeck I had a hunch that this might be somehow related to JENKINS-48115.

          tario, do you have the jira-steps-plugin installed in your environment? If so, what version of the jira-steps-plugin?

          Mark Waite added a comment - danielbeck I had a hunch that this might be somehow related to JENKINS-48115 . tario , do you have the jira-steps-plugin installed in your environment? If so, what version of the jira-steps-plugin?

          Patrick Ruckstuhl added a comment - - edited

          Yes, the latest released version. Not yet the version just released as indicated on that linked issue.

          Patrick Ruckstuhl added a comment - - edited Yes, the latest released version. Not yet the version just released as indicated on that linked issue.

          Mark Waite added a comment - - edited

          tario does the problem resolve itself if you revert the jira-steps-plugin from 1.3.0 to 1.2.1 (or if you upgrade it to jira-steps-plugin 1.3.1)?

          Mark Waite added a comment - - edited tario does the problem resolve itself if you revert the jira-steps-plugin from 1.3.0 to 1.2.1 (or if you upgrade it to jira-steps-plugin 1.3.1 )?

          Will check that in a couple hours, don't have access right now, will let you know.

          Patrick Ruckstuhl added a comment - Will check that in a couple hours, don't have access right now, will let you know.

          Andrew Bayer added a comment -

          Yup, this is JENKINS-48115

          Andrew Bayer added a comment - Yup, this is JENKINS-48115

          I can confirm, upgrading to 1.3.1 fixes everything.

          Patrick Ruckstuhl added a comment - I can confirm, upgrading to 1.3.1 fixes everything.

            Unassigned Unassigned
            tario Patrick Ruckstuhl
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: