Persistet variables not set when build in queue

Continua CI Feature Requests
1

We use persistet variable to track who and when broke tests.
Pipeline is queued, meaning that only one build is possible at a time and it is done by a lock in the Conditions section of that Configuration.
It works well if new build is started after the previous value is persistet.
If build is started in the meantime and is waiting on a lock, it does not notice the persistet value of currently running build.
For me persistet variables should be taken when the build actually starts (after the lock is taken).

2

Hi Michal,

The reason for loading the build variables early is so that they can be used to populate the Queue Options dialog for manual builds. As the value may be changed in this dialog, we can’t reload and therefore overwrite the variables again after this point. It also doesn’t make sense to lock the manual builds before they are started.

We have recently been thinking through options for interacting with configuration, project and application variables during the build process, so it is possible that we could implement something to support your scenario. Can you elaborate more on how you are using the variable to track who and when broke tests - maybe there is another way this can be done?

3

The core functionality for persistent variables is storing last number of failed tests.
We have a configuration that does regression on our master branch, but not all deliveries generate something testable, but we want to know if this particular version is OK, meaning that all previous runs on this version passed tests. But delivery is much quicker that the tests itself, so it often happen that regression is queued.
For this we need persistent variable.

Timeline is as follows:

  1. Deliver to master → SW produced
  2. Run tests → store number of failed tests → mark OK as failed == 0
  3. Deliver to master → SW produced
  4. Deliver to master → no SW produced (tests will be queued)
  5. Run tests → store number of failed tests → mark NOT OK as failed > 0
  6. Verify if previous delivery passed tests → mark OK as last failed set to 0 (see 2)
4

Hi Michal,

Version 1.9.2.1177 includes actions which should help for this scenario. Specially, the Load Variable action which you can use to load the server variable value after the shared resource lock has been acquired

1 Like