programmatically set build number

Details

  • Type: Improvement Improvement
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: www
  • Labels:
    None
  • Environment:
    Platform: All, OS: All

Description

in my case, it would be interesting to have a build number not incremental.
for example, it could be set to the repository revision number, or a number
computed based on the date.

Issue Links

is duplicated by

Improvement - An improvement or enhancement to an existing feature or task. HUDSON-507 Allow for configurable build numbers

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Improvement - An improvement or enhancement to an existing feature or task. HUDSON-684 New post-build action to execute aribtrary shell commands

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kohsuke Kawaguchi added a comment -

We used to have this feature back then. I removed it when I started relying on
the uniqueness of the build number more (such as use of build numbers in URL.)

So I'm bit skeptical for doing this. But if you do this, we just need to be
careful that we only allow build numbers to be increased.

Show
Kohsuke Kawaguchi added a comment - We used to have this feature back then. I removed it when I started relying on the uniqueness of the build number more (such as use of build numbers in URL.) So I'm bit skeptical for doing this. But if you do this, we just need to be careful that we only allow build numbers to be increased.
Hide
Permalink
al_xipe added a comment -

I understand your point.
That makes sense, maybe I should around that as it is a volunteer limitation to
prevent potential problems.
At least I'll put more thinking into this.

One use case I was thinking about that for:
I need to have the same build number accross a many projects.
Actually, each project is the same code built and tested on different platforms.
The ability to garantee a common build number for all the platforms is crucial
for the guys in the field, sustaining or debugging purposes.

Maybe I can think of another way to do this

Show
al_xipe added a comment - I understand your point. That makes sense, maybe I should around that as it is a volunteer limitation to prevent potential problems. At least I'll put more thinking into this. One use case I was thinking about that for: I need to have the same build number accross a many projects. Actually, each project is the same code built and tested on different platforms. The ability to garantee a common build number for all the platforms is crucial for the guys in the field, sustaining or debugging purposes. Maybe I can think of another way to do this
Hide
Permalink
Kohsuke Kawaguchi added a comment -
      • Issue 507 has been marked as a duplicate of this issue. ***
Show
Kohsuke Kawaguchi added a comment -
      • Issue 507 has been marked as a duplicate of this issue. ***
Hide
Permalink
dgreen added a comment -

I'm interested in this feature. In our case, the SVN revision number is our build number. With other CI
servers the algorithm to create a new build number would be as follows:

String buildNumber = getSvnRevision()
if (inUse(buildNumber)) {
buildNumber = buildNumber+uniqueBuildNumberSequence().nextVal()
}

This would guarantee a unique build number for every build, but if possible the build number is based
on the SVN revision.

The main priority for us is that the build artifacts be accessible via an URL that is SVN-revision based.
If it's not possible to have a build number be the SVN revision, then perhaps some kind of build alias
would be sufficient.

Show
dgreen added a comment - I'm interested in this feature. In our case, the SVN revision number is our build number. With other CI servers the algorithm to create a new build number would be as follows: String buildNumber = getSvnRevision() if (inUse(buildNumber)) { buildNumber = buildNumber+uniqueBuildNumberSequence().nextVal() } This would guarantee a unique build number for every build, but if possible the build number is based on the SVN revision. The main priority for us is that the build artifacts be accessible via an URL that is SVN-revision based. If it's not possible to have a build number be the SVN revision, then perhaps some kind of build alias would be sufficient.
Hide
Permalink
dgreen added a comment -

watch this issue

Show
dgreen added a comment - watch this issue
Hide
Permalink
huybrechts added a comment -

I've just committed some functionality to the description-setter plugin that may
help. You can use the description-setter to set the description of a build.
Later you can retrieve a build by using this url:
/job/<jobName>/by-description/<description>. In your case the description would
be the SVN revision.

Show
huybrechts added a comment - I've just committed some functionality to the description-setter plugin that may help. You can use the description-setter to set the description of a build. Later you can retrieve a build by using this url: /job/<jobName>/by-description/<description>. In your case the description would be the SVN revision.
Hide
Permalink
dgreen added a comment -

great! I can't wait to try it out.

Show
dgreen added a comment - great! I can't wait to try it out.
Hide
Permalink
jlongman added a comment -

I'd like to be able to share the build number between jobs.

With a universal increasing build number we can stop including internal build
details to customers and make it simple, but still track whether something comes
from an developer, an incremental, a nightly, or an official.

This still maintains the properties that koshuke used to justify removing the
programmatic settings.

Show
jlongman added a comment - I'd like to be able to share the build number between jobs. With a universal increasing build number we can stop including internal build details to customers and make it simple, but still track whether something comes from an developer, an incremental, a nightly, or an official. This still maintains the properties that koshuke used to justify removing the programmatic settings.
Hide
Permalink
Kohsuke Kawaguchi added a comment -

In 1.390, the display name of a build is modifiable.
Committed in ad27bab4e74178aa86a973acb20d6c0747aad894

Show
Kohsuke Kawaguchi added a comment - In 1.390, the display name of a build is modifiable. Committed in ad27bab4e74178aa86a973acb20d6c0747aad894

People

  • Assignee:
    al_xipe
    Reporter:
    al_xipe
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: