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

Provide a way to run pipeline steps with ambiguous step names

    Details

    • Similar Issues:
    • Released As:
      workflow-cps 2.55

      Description

      Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. The instance has 3 plugins installed that define distinct steps whose function names are all echo), any Pipelines that use echo will always use the first implementation (based on Extension ordering of the descriptor for each step), and there is no way for the user to specify that they want to use a different implementation.

      Usually, it makes sense for the developers who created the steps with the same name to just rename them so they are distinct to prevent this problem, and developers of new Pipeline steps are able to use the Step extension listing to browse all open source step implementations to ensure they are not reusing an existing step name. However, there is no way for open source developers to discover step names used by proprietary plugins, so it is possible for an open source developer to inadvertently reuse a step name that is already being used by a proprietary plugin.

      To work around this issue, we should provide a way to execute a step unambiguously. For example:

      echo "Hello, world!" // Normal echo step
      'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
      

      For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.

        Attachments

          Issue Links

            Activity

            dnusbaum Devin Nusbaum created issue -
            dnusbaum Devin Nusbaum made changes -
            Field Original Value New Value
            Description Currently, if there are multiple {{Step}}s with the same function name in Jenkins (e.g. 3 plugins defining distinct Steps whose function names are all {{echo}}), any Jenkinsfiles that use {{echo}} will always use the first implementation (based on Extension ordering in Jenkins), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps to just rename them so they are distinct to prevent this problem entirely. Developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name, but there is no equivalent for proprietary plugins, so this could happen even if developers do their best to not use existing step names.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. 3 plugins defining distinct Steps whose function names are all {{echo}} are installed at the same time), any Jenkinsfiles that use {{echo}} will always use the first implementation (based on Extension ordering of the step's descriptors), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps to just rename them so they are distinct to prevent this problem entirely. Developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name, but there is no equivalent for proprietary plugins, so this could happen even if developers do their best to not use existing step names.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            dnusbaum Devin Nusbaum made changes -
            Description Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. 3 plugins defining distinct Steps whose function names are all {{echo}} are installed at the same time), any Jenkinsfiles that use {{echo}} will always use the first implementation (based on Extension ordering of the step's descriptors), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps to just rename them so they are distinct to prevent this problem entirely. Developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name, but there is no equivalent for proprietary plugins, so this could happen even if developers do their best to not use existing step names.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. 3 plugins defining distinct Steps whose function names are all {{echo}} are installed at the same time), any Jenkinsfiles that use {{echo}} will always use the first implementation (based on Extension ordering of the step's descriptors), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps with the same name to just rename them so they are distinct to prevent this problem, and developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name. However, there is no way for open source developers to discover step names used by proprietary plugins, so it is possible for an open source developer to inadvertently reuse a step name that is already being used by a proprietary plugin.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            dnusbaum Devin Nusbaum made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            dnusbaum Devin Nusbaum made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            dnusbaum Devin Nusbaum made changes -
            Remote Link This issue links to "jenkinsci/workflow-cps-plugin#239 (Web Link)" [ 21420 ]
            dnusbaum Devin Nusbaum made changes -
            Description Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. 3 plugins defining distinct Steps whose function names are all {{echo}} are installed at the same time), any Jenkinsfiles that use {{echo}} will always use the first implementation (based on Extension ordering of the step's descriptors), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps with the same name to just rename them so they are distinct to prevent this problem, and developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name. However, there is no way for open source developers to discover step names used by proprietary plugins, so it is possible for an open source developer to inadvertently reuse a step name that is already being used by a proprietary plugin.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            Currently, if there are multiple Pipeline steps with the same function name in a Jenkins instance (e.g. The instance has 3 plugins installed that define distinct steps whose function names are all {{echo}}), any Pipelines that use {{echo}} will always use the first implementation (based on Extension ordering of the descriptor for each step), and there is no way for the user to specify that they want to use a different implementation.

            Usually, it makes sense for the developers who created the steps with the same name to just rename them so they are distinct to prevent this problem, and developers of new Pipeline steps are able to use the [Step extension listing|https://jenkins.io/doc/developer/extensions/workflow-step-api/#step] to browse all open source step implementations to ensure they are not reusing an existing step name. However, there is no way for open source developers to discover step names used by proprietary plugins, so it is possible for an open source developer to inadvertently reuse a step name that is already being used by a proprietary plugin.

            To work around this issue, we should provide a way to execute a step unambiguously. For example:

            {code}
            echo "Hello, world!" // Normal echo step
            'org.jenkinsci.plugins.workflow.steps.EchoStep'('Hello, world!') // Same as above, but refers to echo by the full class name
            {code}

            For now, this appears to be a very rare case, so it this basic workaround seems ok, but if it becomes more common maybe we could provide a more sophisticated way to bind step names as used in a Jenkinsfile to the desired Step implementations.
            dnusbaum Devin Nusbaum made changes -
            Status In Review [ 10005 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Released As workflow-cps 2.55

              People

              • Assignee:
                dnusbaum Devin Nusbaum
                Reporter:
                dnusbaum Devin Nusbaum
              • Votes:
                1 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: