Hi@javicalle

Thank you for so detailed information. It seems that the branch name is not resolved correctly. Please use feature/logPropsCertificate directly instead of reading from variable to see if the commit is correct.

Hi@steveluo,
I will check ASAP, but you can notice that step is aware of the correct branch value because of this:

13:14:38,254 DEBUG - Executing command: git fetch origin feature/logPropsCertificate 
13:14:38,254 DEBUG - Command working directory: /tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy
.../...
13:14:38,556 ERROR - From gitea.grupoci.local:dms/srv-proxy
13:14:38,556 ERROR -  * branch            feature/logPropsCertificate -> FETCH_HEAD

All this log is native from the QB step (the ERROR level is because the command sysout).

But then the checkout is from commit 96f5dfdc7a:

13:14:38,573 DEBUG - Executing command: git checkout -f 96f5dfdc7a93d7b851c6ceb070c5ac6bb5a212ad

I'll update with the results.

Thanks.

@javicalle what is your QuickBuild version? I found a similar old bug in QB 9.0:

steveluo

@javicalle what is your QuickBuild version? I found a similar old bug in QB 9.0:

I updated my first post after the previous reply:

Our QB is v14.0.7.

I indeed that behavior in bug seems similar to mine, but we can't access to the bug fix (https://build.pmease.com/build/5030) to investigate more.
We also have 2 repositories (in our case 1 Git & 1 SVN).
In our case will not be easy to test with just 1 repo (not sure if is relevant in that bug). I will update my tests.

Thanks for your time.

Some updates after a few tests...

At this moment the repo commits hiistory is like that:

Creating a new repo with the "Branch Name" hardcoded to feature/logPropsCertificate invoked from a "Repository > Checkout" step, the behavior is the expected one:

16:42:55,272 INFO  - Checking step execute condition...
16:42:55,273 INFO  - Step execute condition satisfied, executing...
16:42:55,394 INFO  - Executing pre-execute action...
16:42:55,394 INFO  - Running step...
16:42:55,395 INFO  - Checking out revision 'cf1b4aa7e7b6e35ef94447082adb0d4c61807cdf' of repository 'Gitea DMS Servicios Proxy - Test'...
16:42:55,395 DEBUG - sync working directory [/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy]...
16:42:55,395 DEBUG - Detect whether repository settings have been changed ...
16:42:55,395 DEBUG - Loading scm rc file ...
16:42:55,395 WARN  - Repository RC file /tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy/.qbcache/qb-scm.xml doesn't exist!
16:42:55,395 INFO  - Repository does not exist, creating...
16:42:55,396 DEBUG - Creating git repository to directory [/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy] ...
16:42:55,396 DEBUG - Executing command: git clone --no-checkout alm_gitea@gitea.grupoci.local:dms/srv-proxy.git /tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy 
.../...
16:42:55,402 DEBUG - Cloning into '/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy'...
16:42:55,860 DEBUG - Executing command: git remote prune origin 
.../...
16:42:56,135 DEBUG - Executing command: git fetch 
.../...
16:42:56,382 DEBUG - Executing command: git fetch origin feature/logPropsCertificate 
.../...
16:42:56,603 ERROR - From gitea.grupoci.local:dms/srv-proxy
16:42:56,603 ERROR -  * branch            feature/logPropsCertificate -> FETCH_HEAD
16:42:56,617 DEBUG - Saving scm rc file ...
16:42:56,620 DEBUG - Saving scm rc file ...
16:42:56,622 DEBUG - Executing command: git checkout -f cf1b4aa7e7b6e35ef94447082adb0d4c61807cdf 
.../...
16:42:56,629 WARN  - Note: checking out 'cf1b4aa7e7b6e35ef94447082adb0d4c61807cdf'.
16:42:56,629 WARN  -
16:42:56,629 WARN  - You are in 'detached HEAD' state. You can look around, make experimental
16:42:56,629 WARN  - changes and commit them, and you can discard any commits you make in this
16:42:56,629 WARN  - state without impacting any branches by performing another checkout.
16:42:56,629 WARN  -
16:42:56,629 WARN  - If you want to create a new branch to retain commits you create, you may
16:42:56,629 WARN  - do so (now or later) by using -b with the checkout command again. Example:
16:42:56,629 WARN  -
16:42:56,629 WARN  -   git checkout -b new_branch_name
16:42:56,630 WARN  -
16:42:56,630 INFO  - HEAD is now at cf1b4aa... Log propiedades certificado
16:42:56,730 INFO  - Executing post-execute action...

If we revert the hardcoded value to ${vars.getValue("GIT_TTB")} the behavior becomes again the 'unexpected' one, checking out the master commit:

17:10:16,687 INFO  - Checking step execute condition...
17:10:16,687 INFO  - Step execute condition satisfied, executing...
17:10:16,808 INFO  - Executing pre-execute action...
17:10:16,808 INFO  - Running step...
17:10:16,809 INFO  - Checking out revision '96f5dfdc7a93d7b851c6ceb070c5ac6bb5a212ad' of repository 'Gitea DMS Servicios Proxy - Test'...
17:10:16,809 DEBUG - sync working directory [/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy]...
17:10:16,809 DEBUG - Detect whether repository settings have been changed ...
17:10:16,809 DEBUG - Loading scm rc file ...
17:10:16,809 WARN  - Repository RC file /tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy/.qbcache/qb-scm.xml doesn't exist!
17:10:16,809 INFO  - Repository does not exist, creating...
17:10:16,809 DEBUG - Creating git repository to directory [/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy] ...
17:10:16,810 DEBUG - Executing command: git clone --no-checkout alm_gitea@gitea.grupoci.local:dms/srv-proxy.git /tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy
.../...
17:10:16,815 DEBUG - Cloning into '/tmp/quickbuild/workspaces/root/RHEL/Dms7.X/ServiciosProxy/source/srv-proxy'...
17:10:17,293 DEBUG - Executing command: git remote prune origin 
.../...
17:10:17,558 DEBUG - Executing command: git fetch 
.../...
17:10:17,822 DEBUG - Executing command: git fetch origin feature/logPropsCertificate 
.../...
17:10:18,068 ERROR - From gitea.grupoci.local:dms/srv-proxy
17:10:18,068 ERROR -  * branch            feature/logPropsCertificate -> FETCH_HEAD
17:10:18,079 DEBUG - Saving scm rc file ...
17:10:18,081 DEBUG - Saving scm rc file ...
17:10:18,083 DEBUG - Executing command: git checkout -f 96f5dfdc7a93d7b851c6ceb070c5ac6bb5a212ad 
.../...
17:10:18,089 WARN  - Note: checking out '96f5dfdc7a93d7b851c6ceb070c5ac6bb5a212ad'.
17:10:18,089 WARN  -
17:10:18,089 WARN  - You are in 'detached HEAD' state. You can look around, make experimental
17:10:18,089 WARN  - changes and commit them, and you can discard any commits you make in this
17:10:18,089 WARN  - state without impacting any branches by performing another checkout.
17:10:18,089 WARN  -
17:10:18,089 WARN  - If you want to create a new branch to retain commits you create, you may
17:10:18,089 WARN  - do so (now or later) by using -b with the checkout command again. Example:
17:10:18,089 WARN  -
17:10:18,089 WARN  -   git checkout -b new_branch_name
17:10:18,089 WARN  -
17:10:18,089 INFO  - HEAD is now at 96f5dfd... Inicializando repositorio.
17:10:18,090 INFO  - Executing post-execute action...

We must note again that QB is getting the right ${vars.getValue("GIT_TTB")} value because it is using it inside the step:

17:10:17,822 DEBUG - Executing command: git fetch origin feature/logPropsCertificate

and:

17:10:18,068 ERROR - From gitea.grupoci.local:dms/srv-proxy
17:10:18,068 ERROR -  * branch            feature/logPropsCertificate -> FETCH_HEAD

We can not check at this moment but our assumption, knowing other behaviors of the repositories in QB, is that QB is 'calculating' the commit to checkout before assigning values to variables. Then is doing the needed steps to checkout the repo with the values calculated, but it has the wrong commit to checkout.

From our standing, is not unusual to get the branch to work with at runtime, and seems that this is not a common problem. So or we have missed something in our configuration or people is not using like this.
I can't suppose that create a repo for every development branch should be needed to make it work.
How must we configure the repo to get the branch to checkout at runtime? (In our use case, the branch to choose come from previous steps in our configuration)

Thanks in advanced.

Hi@javicalle

Use variable in branch name is a very common usage. In fact, QuickBuild itself uses this method to release different version branches. I guess it may be related to how you set up your variable. From what you mentioned, it seems that you set the variable value from previous step:

In our use case, the branch to choose come from previous steps in our configuration

Could you please show me how you did here? It would be more helpful if you can set up a demo configuration to reproduce this and send the database to me (steve at pmease), or you can send me your repository definition, variable definition, steps definition (especially the step where to set branch variable).

I will try to give to you all the QB definition (the easy part) before trying to create a test configuration.

The repo definition is already known:

The vars are defined as:

Some comments:

• Some vars used in GIT_REPO_URL value are static and inherited from higger config levels
• The GIT_PROJECT is defined in our step config level. The value is initialized after every execution. More details later.
• The GIT_TTB is inherited from higger config levels. The value is cleared after every execution. More details later.

Steps structure:

This is the general structure:

A (very) simplificates view would be:

• the configuration gets a file from our ticketing app
• every row in file have information (; separated)
• for every row:
  • export the git code
  • build
  • perform code analysis
  • publish artifact
• update ticket

The relevant parts:

• At the Process Projects File there is a Post-Execute Action that 'Execute a script' that manages the `pos execution values for some vars:

groovy:
// Clear temporal variables
vars.get("GIT_TTB").setValue("");
vars.get("GIT_PROJECT").setValue("dms/srv-proxy"); // Set default repo to avoid error on check git repo available when start build
.../...

• At the Process Artifact there is a Pre-Execute Action that 'Execute a script' setting the GIT_TTB var:

groovy:
/* ************************************************************************************
 * Script que actualiza las variables necesarias para la ejecución de los steps
 * ************************************************************************************/
  import com.pmease.quickbuild.QuickbuildException;

  String projectRepo = "";
  String projectTagBranch = "";

  try {
    .../...
    String project = params.get("DMS_PROJECT_TO_BUILD");
    ArrayList<String> projectAttributes = project.tokenize(";");
	.../...
    projectRepo = projectAttributes[1];
    projectBranchTag = projectAttributes[2];

    logger.debug("REPO: " + projectRepo);
    logger.debug("BRANCH: " + projectBranchTag);

    // actualizamos las variables con los valores necesarios para la construcción
    vars.get("GIT_PROJECT").setValue(projectRepo);
    vars.get("GIT_TTB").setValue(projectBranchTag);
    .../...
    build.flushVariables();

  } catch (QuickbuildException qbex) {
    logger.error("ERROR parseando artefacto a construir "+project);
    throw new QuickbuildException("Step "+step.getName()+" failed.");
  }

• The old Export Code is just a "Repository > Checkout" step with no particular configuration. It have the Git Repository configured.

If you still consider it appropriate to generate the demo configuration, please tell us how we can export the database to send it yo you.

Thanks a lot for so detailed information and I can reproduce the issue now.

You can't set branch/commit variable in the step as it violates the mechanism of QuickBuild. Before start a build, QuickBuild need take a snapshot for a configuration, this includes fixing the value of variables, selecting the build agent, and most importantly, calculating the head revision of repository. So, that means the head revision has already been calculated before build starts, because QuickBuild needs this revision to determine whether or not to start a build, for example, you can see there are some options related to changes in configuration Build Condition setting. So, no matter how you set branch value in the step, QuickBuild still checks out the head revision calculated instead. That is what you have already found in the build log. And in your case, the change log is also inaccurate, because you may change to another branch in next build, that means the change log is from different branches.

The solution can be one of below:

1. Separate the configuration, so you can calculate the branch in one configuration, then pass the variable to trigger another configuration to do the real check out and build.
2. In configuration Advanced Setting section, there is a field Pre-Queue Script which will be executed before build starts, so you can calculate the branch name there.
3. Use Shell/Batch Command Step instead. You can use any git command yourself.

Hi@steveluo,
Thank you so much for reviewing our case and providing a detailed explanation of the behavior we are experiencing. This behavior in QB has been bothering us from time to time, and we wanted to understand it because it seems a bit counterintuitive to us. That's why we ended up opening this ticket.

Once this is understood, we must say that of the proposed options, we had already implemented option (3) (the disabled Export code in image).
Option (1) is not viable for the same reason: at this stage, it is not yet possible to know the value of the branch.
Option (2) is promising. May I ask if this is the one used in QB builds?

steveluo

Use variable in branch name is a very common usage. In fact, QuickBuild itself uses this method to release different version branches.

I suppose we could define a generic configuration that performs some of the related steps (one configuration just to invoke the step "Repository Checkout" seems a bit excessive). I think it's an approach worth exploring.

Just to be sure, the approach would be:

• to create a separate configuration for the repository checkout (here we will use vars to get the branch value)
• adding the configuration in our flow with an step of type Trigger Other Builds with the new configuration
  • configure in step the Variables values, ie: the branch to checkout

Thanks in advanced.

Hi@javicalle

javicalle

Option (2) is promising. May I ask if this is the one used in QB builds?

No, the usage in QuickBuild is very simple. The variables we use in QuickBuild are just there for inheritance. For example, we have QB10, QB11, QB12..., and each branch name is just same as the configuration name we created, so we define the repository in parent configuration and define the branch name by a variable to get current configuration name.

javicalle

• to create a separate configuration for the repository checkout (here we will use vars to get the branch value)
• adding the configuration in our flow with an step of type Trigger Other Builds with the new configuration
  • configure in step the Variables values, ie: the branch to checkout

Do you want to try option (1) here? Yes, you can calculate the variables in Trigger Build Step: