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.

Variable evaluation time and other QB concepts #2398

mmuszyns ·
Hi,

I have few questions about the way QB works:

1. I have a configuration variable which has a script inside, e.g. VAR_X = ${groovy: some_calculations_here}. I'd like to use it a number of times throughout the build process. Does QB evaluate it once at the beginning or each time I refer to it?
2. I have a configuration where build duration is about 1 hour. This configuration can be triggered number of times during 1 hour, so next few builds are queued by QB. Triggering step passes some variables, one of them is used as a build version and also in repository definition (i.e. as a part of config spec in ClearCase or changeset to build in Git). When exactly are those variables being evaluated?
3. In which order do these steps run?
- checking build condition
- pre-queue script
- calculating build version
- evaluating used variables
- evaluating repository definition if there are some groovy scripts in it
- calculating changes since previous build
- pre-build script
- snapshot taking
4. Checking build condition and calculating changes in ClearCase builds can take some time and cleartool command used in this process takes a lot of CPU. Can I dispatch it to few agents or does it have to run on QB server?
5. What exactly does a new option 'Record SCM changes'? Because I think I saw SCM changes in build overview even when this option was disabled. Also, does it speed up the build?
6. http://wiki.pmease.com/display/QB50/Commit+Command - if my issue tracker is not supported by QB do I have to first write a custom plugin similar to Trac/Bugzilla/JIRA plugin to be able to use this part of documentation and modify issues that are in build's changeset?
  • replies 5
  • views 1776
  • stars 0
robinshen ADMIN ·
Please see my answer per your question below:

[quote="mmuszyns"]Hi,

I have few questions about the way QB works:

1. I have a configuration variable which has a script inside, e.g. VAR_X = ${groovy: some_calculations_here}. I'd like to use it a number of times throughout the build process. Does QB evaluate it once at the beginning or each time I refer to it?
>> Variables will be evaluated everytime you access it. The only exception is when you pass variables in trigger build step, and in this case variable will only be evaluated first and then pass to triggered build.
2. I have a configuration where build duration is about 1 hour. This configuration can be triggered number of times during 1 hour, so next few builds are queued by QB. Triggering step passes some variables, one of them is used as a build version and also in repository definition (i.e. as a part of config spec in ClearCase or changeset to build in Git). When exactly are those variables being evaluated?
>> Variables explicitely passed to a build for instance via trigger build step will always override same variables defined in triggered configuration, so in this case, it will be evaluated once and then pass to triggered build.
3. In which order do these steps run?
- checking build condition
- pre-queue script
- calculating build version
- evaluating used variables
- evaluating repository definition if there are some groovy scripts in it
- calculating changes since previous build
- pre-build script
- snapshot taking
>> The correct order is:
1) pre-queue script
2) checking build condition, if build condition states "if changes found in referenced repositories", QB will go ahead to calculate changes while evaluating the condition; otherwise, changes calculation will be done at the time checking out that repository if "record SCM changes" option is enabled. Before calculating changes, QB takes snapshot of repository first.
3) If build condition is satisfied, QB proceed to calculate next build version.
4) QB runs pre-build script before proceeding to run defined steps of the configuration.
Script evaluation will be done each time the variable or repository field is accessed.

4. Checking build condition and calculating changes in ClearCase builds can take some time and cleartool command used in this process takes a lot of CPU. Can I dispatch it to few agents or does it have to run on QB server?
>> If the master step is set to run on agent, the change calculation will be done on that agent.

5. What exactly does a new option 'Record SCM changes'? Because I think I saw SCM changes in build overview even when this option was disabled. Also, does it speed up the build?
>> This option tells QB whether or not to calculate SCM changes even if the changes calculation is not necessary for the build. This means that if this option is turned off, and if the build condition does not contain logic such as "if changes found in referenced repositories", QB will not try to record changes in checkout step. However if the build condition contains that logic, QB will still try to calculate the SCM changes in regardless of value of "record SCM changes", but will not record it to be displayed.

6. http://wiki.pmease.com/display/QB50/Commit+Command - if my issue tracker is not supported by QB do I have to first write a custom plugin similar to Trac/Bugzilla/JIRA plugin to be able to use this part of documentation and modify issues that are in build's changeset?[/quote]
>> Yes a custom plugin will be necessary to parse commits and call remote API of your issue tracker to change issue status.
mmuszyns ·
Robin, thanks a lot for those answers, they're really helpful!

I have one additional question, though:

2) checking build condition, if build condition states "if changes found in referenced repositories", QB will go ahead to calculate changes while evaluating the condition; otherwise, changes calculation will be done at the time checking out that repository if "record SCM changes" option is enabled. Before calculating changes, QB takes snapshot of repository first.


By snapshot taking do you mean a full git clone / clearcase checkout using configspec from repository definition or are there some tricks used like 'git pull', 'cleartool update' or shallow clone in Git? Because checkout step sometimes takes a lot of time (we have few 600 MB Git repositories and checkouts from ClearCase can have similar sizes) and it would be nice not to clone the exact same state of repository twice during each build. Does QB somehow reuse the snapshot during checkout step?
robinshen ADMIN ·
The snapshot taking is to get current head revision of remote repository. In case of Git, QB has to clone it first (or if you not clean up workspace for previous build, it will just be a pull) then call log to get the current head commit, for subsequent checkout steps, QB will no longer call clone again. For ClearCase, the snapshot taking is simply getting current timestamp, and the ClearCase view will be updated once at the time calculating changes, and this will be updated only once during a build.
kururin ·

Hello

This is a very old topic but could you confirm the order is still correct in the latest QB version?

1) pre-queue script
2) checking build condition, if build condition states "if changes found in referenced repositories", QB will go ahead to calculate changes while evaluating the condition; otherwise, changes calculation will be done at the time checking out that repository if "record SCM changes" option is enabled. Before calculating changes, QB takes snapshot of repository first.
3) If build condition is satisfied, QB proceed to calculate next build version.
4) QB runs pre-build script before proceeding to run defined steps of the configuration.
Script evaluation will be done each time the variable or repository field is accessed.

4. Checking build condition and calculating changes in ClearCase builds can take some time and cleartool command used in this process takes a lot of CPU. Can I dispatch it to few agents or does it have to run on QB server?
>> If the master step is set to run on agent, the change calculation will be done on that agent.

Thank you!

robinshen ADMIN ·

Yes still the same