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

Support for overriding value of BUILDS_ALL_TIME (etc.) by environment-variables

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Status Quo:

      Currently, the values for ${BUILDS_ALL_TIME}, ${BUILDS_TODAY}, ${BUILDS_THIS_MONTH} and ${BUILDS_THIS_YEAR} will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

      Problem:

      For automated builds this is not practicable, because it requires way too much manual interaction / modification.

      Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

      Feature-Request:

      A useful extension to the versionnumber plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override - by hand - the next value with a number):

      Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
      However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

      Solution:

      I already have implemented this extension and will provide a pull-request.
      I hope others will find this extension useful so that it gets integrated.

        Attachments

          Activity

          bahadir Deniz Bahadir created issue -
          bahadir Deniz Bahadir made changes -
          Field Original Value New Value
          Description Currently, the values for _${BUILDS_ALL_TIME}_, _${BUILDS_TODAY}_, _${BUILDS_THIS_MONTH}_ and , _${BUILDS_THIS_YEAR}_ will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

          For automated builds this is not practicable, because it requires way too much manual interaction / modification.

          Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

          A useful extension to the _versionnumber_ plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override -by hand- the next value with a number):

          Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
          However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

          I already have implemented this extension and will provide a pull-request.
          I hope others will find this extension useful so that it gets integrated.
          h4. Status Quo:

          Currently, the values for _$\{BUILDS_ALL_TIME\}_, _$\{BUILDS_TODAY\}_, _$\{BUILDS_THIS_MONTH\}_ and _$\{BUILDS_THIS_YEAR\}_ will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

          h4. Problem:

          For automated builds this is not practicable, because it requires way too much manual interaction / modification.

          Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

          h4. Feature-Request:

          A useful extension to the _versionnumber_ plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override -by hand- the next value with a number):

          Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
          However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

          h4. Solution:

          I already have implemented this extension and will provide a pull-request.
          I hope others will find this extension useful so that it gets integrated.
          bahadir Deniz Bahadir made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          bahadir Deniz Bahadir made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          bahadir Deniz Bahadir made changes -
          Description h4. Status Quo:

          Currently, the values for _$\{BUILDS_ALL_TIME\}_, _$\{BUILDS_TODAY\}_, _$\{BUILDS_THIS_MONTH\}_ and _$\{BUILDS_THIS_YEAR\}_ will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

          h4. Problem:

          For automated builds this is not practicable, because it requires way too much manual interaction / modification.

          Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

          h4. Feature-Request:

          A useful extension to the _versionnumber_ plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override -by hand- the next value with a number):

          Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
          However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

          h4. Solution:

          I already have implemented this extension and will provide a pull-request.
          I hope others will find this extension useful so that it gets integrated.
          h4. Status Quo:

          Currently, the values for _$\{BUILDS_ALL_TIME\}_, _$\{BUILDS_TODAY\}_, _$\{BUILDS_THIS_MONTH\}_ and _$\{BUILDS_THIS_YEAR\}_ will only increase by 1 for each new (successful) build. The only exception to this is explicitly overriding the next value by hand.

          h4. Problem:

          For automated builds this is not practicable, because it requires way too much manual interaction / modification.

          Sometimes it would be beneficial if another (upstream) build-job could provide a new number for one of these values or if it could be calculated outside of Jenkins and injected into the build-process.

          h4. Feature-Request:

          A useful extension to the _versionnumber_ plugin which solves this short-coming would be to extend the usage of the form-fields in the job-configuration (, which currently are only used to override - by hand - the next value with a number):

          Instead of just taking a number which overrides the value for the next build, it should be possible to provide an environment-variable in this field. This environment-variable should then be checked during the next build and its value used as the corresponding number.
          However, if during the next build that environment-variable is not set or its value is not convertible into an integer, the standard behavior should kick in as if the field would have been left blank. (This means, the corresponding value of the previous build should be taken and increased by 1, and that value should be used instead.)

          h4. Solution:

          I already have implemented this extension and will provide a pull-request.
          I hope others will find this extension useful so that it gets integrated.
          bahadir Deniz Bahadir made changes -
          Assignee Deniz Bahadir [ bahadir ]
          bahadir Deniz Bahadir made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 164002 ] JNJira + In-Review [ 208929 ]

            People

            • Assignee:
              bahadir Deniz Bahadir
              Reporter:
              bahadir Deniz Bahadir
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: