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

RTC build property names: Underscore chars "swallowed"

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • teamconcert-plugin
    • - Jenkins version: 2.107.3
      - "Team Concert" plugin version: 1.2.0.4
      - Actual builds running on Windows 7 virtual machines (dynamically created clones of a snapshot) using Ant version 1.8.2

      I have a number of build properties defined in the RTC build definition (Hudson/Jenkins type). The name of many of these build properties contain underscore "_" characters (the name of the properties themselves, not their values).

      On Jenkins side, I try to access these build properties through the Windows environment variables (by copying them to Ant properties using the Ant task "<property environment="env", .../>). I can "see" all RTC build properties in Ant, but the underscore characters of every RTC build property name are gone!

      Example: An RTC build property with the name "property_name_with_underscores" will appear as a Windows environment variable in the Jenkins job as "propertynamewithunderscores".

      Is this a bug or intended behaviour? If the former: (When) can/will it be fixed? If the latter: Why, how does this make sense?

      See also my related post in Wiki: https://wiki.jenkins.io/display/JENKINS/Team+Concert+Plugin?focusedCommentId=172917031#comment-172917031

          [JENKINS-57220] RTC build property names: Underscore chars "swallowed"

          Sridevi Sangaiah added a comment - - edited

          bernddasbrot

          The current behavior when exporting the build properties from RTC build definition to environment variables in Jenkins build is to keep only alpha-numeric characters, change '.' to '_' and ignore the rest. If the result is empty or begins with a digit then no environment variable is created for that property. This is because of the restrictions on the characters allowed in environment variable names in some operating systems as described in Allowed characters in Linux environment variable names

          See comment 28 in
          259131: HPI: Expose RTC Build properties in the Jenkins build environment
          Having said that since '_' can be included in the name of the environment variables, if the build property name contains '_' it should be retained. '_' in the property names being ignored is a defect in the teamconcert plugin. Though it is unlikely that there are existing builds which have '_' in the property names in the build definition and ignores '_' when referring to them in Jenkins build, otherwise this issue would have been reported earlier, this scenario can't be ruled out while making the fix.

          In the mean time would it be possible for you to use '.' in the name of the properties added in the build definition which would then be converted to '_' by the teamconcert plugin when creating the corresponding environment variables in Jenkins.

          Sridevi Sangaiah added a comment - - edited bernddasbrot The current behavior when exporting the build properties from RTC build definition to environment variables in Jenkins build is to keep only alpha-numeric characters, change '.' to '_' and ignore the rest. If the result is empty or begins with a digit then no environment variable is created for that property. This is because of the restrictions on the characters allowed in environment variable names in some operating systems as described in Allowed characters in Linux environment variable names See comment 28 in 259131: HPI: Expose RTC Build properties in the Jenkins build environment Having said that since '_ ' can be included in the name of the environment variables, if the build property name contains ' _ ' it should be retained. '_ ' in the property names being ignored is a defect in the teamconcert plugin. Though it is unlikely that there are existing builds which have '_ ' in the property names in the build definition and ignores '_' when referring to them in Jenkins build, otherwise this issue would have been reported earlier, this scenario can't be ruled out while making the fix. In the mean time would it be possible for you to use '.' in the name of the properties added in the build definition which would then be converted to '_' by the teamconcert plugin when creating the corresponding environment variables in Jenkins.

          Bernd Wanko added a comment -

          Hello, thank you for the competent answer. Here in my company, we do indeed have a large number of RTC build definitions which contain many build properties with underscores '_' in their names (probably one developer started using them, the others took the first one(s) as example, therefore it became quite common to use property names with underscores here).

          Sure it is possible to rename the build properties and replace '_' by '.', for the moment. But finally, I would prefer not having to do this, having to touch as little and automatize as much as possible.

          Are you saying the behaviour will eventually be changed in a future version of the Team Concert plugin, so underscores '_' are retained? If so: Can you give a rough estimation when the plugin version with this change will be published?

          Bernd Wanko added a comment - Hello, thank you for the competent answer. Here in my company, we do indeed have a large number of RTC build definitions which contain many build properties with underscores '_' in their names (probably one developer started using them, the others took the first one(s) as example, therefore it became quite common to use property names with underscores here). Sure it is possible to rename the build properties and replace '_' by '.', for the moment. But finally, I would prefer not having to do this, having to touch as little and automatize as much as possible. Are you saying the behaviour will eventually be changed in a future version of the Team Concert plugin, so underscores '_' are retained? If so: Can you give a rough estimation when the plugin version with this change will be published?

          At the moment we can not comment on if and when will this behavior be fixed as it has to go through internal discussions. We released 1.3.0 version of the plugin this week and yet to start planning for the next release. Will provide an update as soon as we have more clarity.

          Sridevi Sangaiah added a comment - At the moment we can not comment on if and when will this behavior be fixed as it has to go through internal discussions. We released  1.3.0 version of the plugin this week and yet to start planning for the next release. Will provide an update as soon as we have more clarity.

            Unassigned Unassigned
            bernddasbrot Bernd Wanko
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: