Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Feature request: Show if current step implementation is different from when build was run #4596

stang ·

Preamble:
When viewing a historical build's Step Status (https://{QuckBuildServer}/build/{BuildID}/step_status), one can click on the name of a step to see the implementation of that step.
This will always display the most current implementation of that step, even if the step implementation was different at the time that the build ran.

Request:
Would it be possible to let the user know if the current step implementation is different than it was at the time of the build being looked at in Step Status?

Possible approaches:
I can think of three different ways to handle this:

  1. Use the timestamp of the build, and the configuration history as seen in the Audit Log (eg., https://{QuickBuildServer}/audit/{ConfigurationID}) to determine what the step's implementation was at the time of the build.
    Pitfall: the audit log does not appear to go back forever, so beyond a certain amount of time in the past, it would no longer be possible to reconstruct the step implementation.

  2. At the time of the build, calculate a "hash" of the step's implementation, and save this hash with the build. When inspecting the step during Step Status of that build later, compare the current hash versus the saved hash and if they are different, tell the user that the step has changed.
    Drawback: This would not tell the user exactly what the change was. However, simply knowing if the implementation has changed can be useful for debugging.

  3. At the time of the build, save the full implementation of the step with that build.
    Drawback: this may cause builds to use up considerably more storage than they currently do, so I do not consider this option very viable.

edit: fixed formatting

  • replies 3
  • views 180
  • stars 1
robinshen ADMIN ·

Thanks for all the recommendations. This can be pretty hard in QB due to its design choices. Besides steps, repositories, variables and even scripts also contribute to a build, and some of them may be inherited.

Audit log is currently not feasible, not only because it can be purged periodically, also because that it is mainly for human read, not something that can be used to restore exact state (which is considerably complicated and will also require more storages and resources). The hash approach also will not work, as when a step/variable changes, it is hard to determine which build in the configuration hierarchy is using it.

drdt ·

I have a more frustrating problem with regards to this, which is, if the step is deleted (or, more often, renamed), then previous builds show that step as completely missing. It would be helpful to put a placeholder in the build record for these situations. Is this more doable?

robinshen ADMIN ·