Build Number changes for each job in a single pipeline causing problems

Build Environment
1

I have noticed that the CIRCLE_BUILD_NUM is incremented per job since each job appears to show as a “new build” in a workflow/pipeline. This behavior causes the following problems:

  1. If your pipeline has N jobs then each invocation of your build (aka pipeline) increments the application build number by N. I would like it to be sequential by 1 like its always been and as it makes conceptual sense.
  2. Referencing artifacts between jobs that have the build number as part of the name becomes problematic and requires a workaround (e.g. first job saves the build number in a file in a shared workspace).
  3. I understand that there is the CIRCLE_WORKFLOW_ID that is unique and stable throughout a workflow but that is a String and not sequential so we can easily see how many builds a particular release went through and to understand which build is the latest compared to another.

I have seen some posts like this one (https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) asking about the same behavior that we’ve all used with other CICD software but the conversations are invariably closed. Can someone explain why CircleCI decided to work this way and what model of build versioning it promotes so I can at least understand the intent? However, if this was not the intent then can we expect the feature (and when) where a single workflow gets a single stable BUILD NUMBER that is numeric and sequentially incremented like the WORKFLOW ID in spirit?

Thank you

2 Likes
2

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.