Repository gets stale after a merge to it and is not usable in a later stage for building

[Charley Burls]

We are trying to implement a CI plan in which we are attempting to automate the following stages:

Stage 1)  Everyday, at 8 PM, merge source_repo to target_repo

Note: target_repo is added as the default repository and remote caching is disabled.

Stage 2) Build new artifacts from target_repo

We can get the merge to work successfully doing this:

Task 1: Source Code Checkout

Task 2: Script

git remote add temp_origin ${bamboo.planRepository.1.repositoryUrl}
git fetch temp_origin source_repo
git merge temp_origin/source_repo
git push temp_origin ${bamboo.planRepository.1.branch}
git remote remove temp_origin

We then attempt to do the build by doing this:

Task 1:  Source Code Checkout

Task 2: Call build script

Now, the problem is that the source code checkout of the build is using the revision prior to the merge in Stage 1. This means that the source code checkout is somehow caching or using some stale revision of the target_repo for some reason, even though the merge is successful. I do observe this message only in cases when the build is using a stale version of the target_repo:

You are in 'detached HEAD' state. 

Could you please advise what solution would be here to ensure the source code checkout obtains the most current revision of target_repo?

Thank you in advance

[Foong]

Source Code Checkout task will only use the revision at the time of the trigger. If there are new commit created before the build start, it will not get the latest commit.

Use the script task to perform the target checkout instead of Source Code Checkout task if you need latest commits.

You may want to try using Merging Strategy at Plan Configuration > Branches > Merging if the source repo is the same as target repo. It will auto merge it and (if the build ended successfully) the merge will be pushed. For more info, refer to Automatic branch merging

[Chris Johnston]

The built-in Source Code Checkout task will always check out the code at a particular commit.  You can find this commit it uses when you look at the build summary for that particular build.  It will have a revision # -- and that is the commit that build# will always check out... including checkout tasks that occur in other stages.

Instead, just write your own custom checkout task using the script task.

In our case, we build on a windows platform, and I have a custom checkout task that looks like this:

set REPO=${bamboo.planRepository.repositoryUrl}
set WORKDIR=${bamboo.build.working.directory}
set BRANCH=${bamboo.planRepository.branch}

if exist %WORKDIR% del /s /q %WORKDIR%
call git clone %REPO% %WORKDIR%
if not %errorlevel% == 0 call :onError "ERROR: Unable to clone %REPO%"

git submodule update --init --recursive

call git clean -xdf
call git checkout -f %BRANCH%
if not %errorlevel% == 0 call :onError "Error: Unable to checkout %BRANCH%"
goto end

:onError
>&2 echo %1
exit 1

:end
echo Source code checkout completed successfully.
exit 0

This will checkout the repo on the particular branch at the latest revision of that branch the moment it is called.