Pre-build snapshot and runtime repo definitions don't play well together #4618

tomz · 2 weeks ago

We are experiencing the following behavior which we think is unintended.

a Repository definition for perforce whose view contains variable-dependent entries we want discoverable at runtime (i.e. //depot/${vars.getvalue('newScripts')}/... //client/Scripts/...)
a build job that does the following in order: conditionally set the variable newScripts to the correct folder, a repo Take Snapshot step, a repo Record Changes step, a repo Checkout step to sync the folder.

A system-defined pre-build script ends up taking a snapshot prior to the build being run, using a default value of the newScripts variable which is incorrect. However, I would have expected that the Take Snapshot and Record Changes steps to operate on a client with the new/correct view, and make the checkout step sync the correct data, but it does not. In the above scenario, the checkout step syncs the incorrect folder, one specified by the default value of the variable as opposed to its new value.

Currently we work around this by setting the "Snapshot Taking" advanced configuration setting to be a null op "groovy: return". Is this by design? Why wouldn't the Take Snapshot step (during the build but after the variable is set) not fix this problem?

Thanks,
Tom Z

replies 3
views 54
stars 0

robinshen ADMIN · 2 weeks ago

Snapshot taking happens before build starts. So if you set the variable in a build step, the variable value can not be picked up while taking repository snapshots. If possible, please set the variable value directly in the snapshot taking script, or in the pre-queue script.

1 Reply

tomz · 2 weeks ago

In our case, a redesign to trigger new builds based on the variable is the only way to do what you're suggesting, but I would have expected the built-in step "Repository-Take Snapshot" to be of help.

I've discovered another bit of weird behavior - if you set the repo user's password in a secret variable but the configuration you are in doesn't inherit that secret variable, the check build condition appears to hang indefinitely, likely in the snapshot taking pre-build script. I would expect the script to error out in the same manner as a bad password and notify the user of a variable not being found.

Thanks for the explanation,
Tom Z

1 Reply

robinshen ADMIN · 2 weeks ago

I've discovered another bit of weird behavior - if you set the repo user's password in a secret variable but the configuration you are in doesn't inherit that secret variable, the check build condition appears to hang indefinitely, likely in the snapshot taking pre-build script. I would expect the script to error out in the same manner as a bad password and notify the user of a variable not being found.

In this case, an empty password was sent to p4, and then p4 wait indefinitely for password input. QB does not simply fails the build as p4 password can actually be empty.