Have TRIBITS_CTEST_DRIVER() checkout branch ${PROJECT_NAME}_BRANCH on all extra repos

[bartlettroscoe]

In order to consistently treat extra repos together with the base base repo as "one big repo", the CI and Nightly testing should occur on the same branch in all of the repos. The TRIBITS_CTEST_DRIVER() function in the file TribitsCTestDriverCore.cmake defines the variable ${PROJECT_NAME}_BRANCH that is used to specify a branch that is checked out on the base repo. This Story is to add the same logic for checking out that same branch on the extra repos.

Definition of Done:

1. If ${PROJECT_NAME}_BRANCH is non-empty, then all of the existing extra repos will also be checked out for this branch as well.

2. Documentation on the behavior of TRIBITS_CTEST_DRIVER() with respect to cloning, pulling updates, and branches. That is:

   a. The default branch cloned is defined by the remote repos.

   b. If ${PROJECT_NAME}_BRANCH is non-empty, then that branch will be checked out in each repo (if a local branch exists). Otherwise, a tracking branch will be created in each repo for the branch ${${PROJECT_NAME}_BRANCH} in the remote repo (as defined by the current tracking branch).

   c. If the repos are already cloned and ${PROJECT_NAME}_BRANCH is empty, then whatever is the current branch will be left alone and a raw pull will be performed.

[jwillenbring]

If there are projects developed independently from the main project, I wonder if this should be an assumption for all cases. Should there be an override? Perhaps a default name for a development branch (e.g. develop or master), and the ability to override that optionally for each extra repo? For example, consider if a package is developed at a University and brought in as an imported package, but also has an independent identity outside of the larger project.

[bartlettroscoe]

If there are projects developed independently from the main project, I wonder if this should be an assumption for all cases.

The key is "independently". If a repo is being listed in Trilinos/cmake/ExtraRepositoriesList.cmake, then it is being continuously integrated and therefore cannot be considered to be "independently developed". If repos are under CI, then the are "dependently developed".

Should there be an override? Perhaps a default name for a development branch (e.g. develop or master), and the ability to override that optionally for each extra repo?

That is possible and we might consider that in the future if there is a strong overriding need, but I don't think that is needed for the repos currently listed in the Trilinos/cmake/ExtraRepositoriesList.cmake file. Also, from and integration perspective, that is likely not a good idea.

Using a different branch name in each repo would break the "one big repo" assumption that is used by the gitdist script (and the basic usage of the Google Repo script too for that matter). For example:

$ gitdist fetch
$ gitdist checkout --track origin/<some-branch-name>

Having a different branch name in each repo breaks that simple standard and is just confusing.

Now, if you want to integrate with an external repo that uses a different name for their branches, then that is fine. That is what you use the checkin-test.py script for with the --extra-pull-from argument. See Multi-Repository Almost Continuous Integration.

For example, consider if a package is developed at a University and brought in as an imported package, but also has an independent identity outside of the larger project.

If that repo is developed in CI with the 'develop' branch of Trilinos, then it would need to adopt the 'develop'/'master' workflow as well to be part of Trilinos CI testing. Otherwise, the university should either set up their own testing against Trilinos 'master' against their 'master', or we need to maintain a separate clone of that repo under github.com/trilinos/<university-repo> that will have a 'develop' and a 'master' branch and then we set up sync processes in and out using the checkin-test.py script like is used in CASL VERA.

To understand why this is so important, let's consider just the xSDKrilinos extra repo and Trilinos. Let's say we did not want to enforce that the xSDKTrilinos repo use the 'develop'/'master' workflow but we did want it to be part of CI and Nightly testing against the Trilinos 'develop' branch. So you would pull Trilinos 'develop' but pull xSDKTrilinos 'master' in automated Trilinos testing. Consider the following three use cases:

1) New feature added to Trilinos and xSDKTrilinos at the same time:

For example, suppose a new function was added to Tpetra that is used immediately in xSDKTrilinos. Therefore, the developer pushes the commits to the Trilinos 'develop' branch and the xSDKTrilinos 'master' branch at the same time. Now this is just fine for Trilinos CI and Nightly testing. But what if a close customer or collaborator wants the more stable version of Trilinos and xSDKTrilinos and they pull the 'master' branches of Trilinos and xSDKTrilinos (e.g. like the installxSDK.sh script will surely be set up to do)? If the update for the Trilinos 'develop' to the 'master' branches has not taken place yet, then when they try to build Trilinos + xSDKTrilinos then they will get a build build error because xSDKTrilinos 'master' is expecting a function in Trilinos/Tpetra 'master' that does not exist yet.

But if xSDKTrilinos uses a 'develop' branch, then the 'master' branches for Trilinos and xSDKTrilinos will always be consistent because they will get updated at the same time. That is what CI means when treating a bunch of repos as "one big repo".

2) Break in backward compatibility in Trilinos that requires coordinated pushes to Trilinos and xSDKTrlinos repos:

Now consider the case where some new experimental functionality in Tpetra that is used in xSDKTrilinos needs to change in a way that breaks backward compatibility. In this case, one needs to push the corresponding commits to Trilinos and xSDKTrilinos at the same time or the Trilinos+xSDKTrilinos CI build will fail. But as soon as you push these changes to Trilinos 'develop' and xSDKTrilinos 'master', if someone where to pull the 'master' branches from these repos then they would get a build failure in xSDKTrilinos because the updated Trilinos/Tpetra would not yet contain the refactored function.

3) Putting out releases of xSDKTrilinos with Trilinos:

When it comes time to release Trilinos with xSDKTrilinos, one would like to simply do:

$ cd Trilinos/
$ ./clone_extra_repos.py
$ gitdist fetch
$ gitdist tag -a trilinos-release-X-Y-start -m "Start of Trilnos X.Y branch" origin/master
$ gitdist checkout -b trilinos-release-X-Y-branch trilinos-release-X-Y-start
$ emacs Version.cmake   # Set Trilinos_REPOSITORY_BRANCH to trilinos-release-X-Y-branch  ...
$ git commit -a -m "Update for Trilinos X.Y release"
$ gitdist push -u origin trilinos-release-X-Y-branch 
$ gitdist push origin trilinos-release-X-Y-start

Then when you set up the automated testing for Trilinos and its extra repos, they will automatically be checked out on the branch Trilinos_REPOSITORY_BRANCH=trilinos-release-X-Y-branch. No argument there, right?

If this does not make sense, then let's talk about this in more detail.

[jwillenbring]

Quote from Ross: The key is "independently". If a repo is being listed in Trilinos/cmake/ExtraRepositoriesList.cmake, then it is being continuously integrated and therefore cannot be considered to be "independently developed". If repos are under CI, then the are "dependently developed".

OK, this makes sense. Where is the documentation concerning the various classes of packages? I think I may have been blurring inserted and imported or something.

[bartlettroscoe]

Reply to @jwillenbring from above comment:

OK, this makes sense. Where is the documentation concerning the various classes of packages? I think I may have been blurring inserted and imported or something.

We need to document that on some Trilinos wiki pages. As we discussed, I will add a new Trilinos Framework GitHub Issue about how to manage repos longer term. Shorter term, I add a wiki page on the currently supported approach being used by TriBITS. Actually, we should take discussion of Trilinos-speicific issues over to trilinos/Trilinos#440.

For the purpose of this TriBITS GitHub issue, we can just document this general approach in the TriBITS Developers Guide.

[bartlettroscoe]

This is a blocker for CASL VERA to move to the 'develop'/'master' workflow so I am putting in ready.

[bartlettroscoe]

This is now complete and pushed to all of the various branches of TriBITS and is being used for CASL VERA and Trilinos testing. The only benefit that Trilinos will get is that it will get the TrilinosRepoVersion.txt file attached as a notes file and it will get the base Triinos commits shown in the Updates.txt file (which will be very nice).

Putting into review to see how this goes with CASL VERA testing (now on the 'nightly' branch) and for Trilinos testing ...

---

DETAILED NOTES:

I need to get this done with some good unit tests.

I need to do this in the casl-dev/master branch becuase CASL needs this for:

• https://vminfo.casl.gov/trac/casl_phi_kanban/ticket/4787

While I am at it, it would also be nice to get the commits for the updated files in the Updates.txt file. Hopefully that will not be too hard.

A) First some initial investigation:

A.1) So what commands are currently getting run to do the update for a VC repo?

Currently, the code the checkouts out the ${PROJECT_NAME}_BRANCH branch for the base repo is written right in the main function TRIBITS_CTEST_DRIVER() and it does a type of hacked git checkout ${${PROJECT_NAME}_BRANCH} first, and if that fails, then does a git checkout --track ${${PROJECT_NAME}_BRANCH}.

Also, looking at the generation of the Updates.txt file, all of that is done for extra repos in the function CLONE_OR_UPDATE_ALL_EXTRAREPOS(). Therefore, that function is not very well named becuase it does more than just clone or update the extra repos. It also appends changes to add to the Updates.txt file.

The function EXTRAREPO_CLEAN_FETCH_RESET() does the update of the branches for an extra repo and makes sure it is clean after people are screwing around. Currenly it does:

$ git clean -fdx
$ git fetch
$ git reset --hard <tracking_branch>

So how are the git repo commits determined? I need to figure that out so that I can determine how to update this function to get on the correct branch and to also determine what commits got pulled. So the current command looks like:

$ git log --name-status -C HEAD ^ORIG_HEAD

which is used to extract the updated commits. This is good because ORIG_HEAD might also work for the base repo where CTest itself did the pull. I will need to confirm that.

Now I need to consider how I would change those git commands so that they will work with a different branch and not screw up the git log --name-satus HEAD ^ORIG_HEAD way getting the updated commits.

And it would be nice if it worked with the extra branch. For example, what if we did:

$ git clean -fdx
$ git reset --hard HEAD
$ git fetch
$ git checkout -f --track origin/${${PROJECT_NAME}_BRANCH}

?

That should get rid of any untracked files, locally modified files, deal with forced pushes to the remote tracking branch, or checkout-out on a detached head state (by getting you on the right branch).

The question is, will ORIG_HEAD be correct for each use case, including for the base repo where CTest does the update for you?

I need to experiment with this some with a few scenarios and see what happens with various use cases to make sure this will work.

Using the Trilinos repo as an example repo (on the 'develop' branch):

$ git pull

$ git log --oneline -1
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git reset --hard HEAD^
HEAD is now at 8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

# Now, this is the initial state of the repo (one commit behind
# github/develop) before updating ...

$ git fetch

$ git checkout -f --track github/develop
fatal: A branch named 'develop' already exists.

Darn, that fails, what will work? Looking at the documentation for git checkout I found the -B option.

$ git checkout -B develop github/develop
Branch develop set up to track remote branch develop from github.
Reset branch 'develop'
Your branch is up-to-date with 'github/develop'.

Okay, so that seems to do the right thing:

$ git log --oneline -C HEAD ^ORIG_HEAD
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

It seems that the -B option for git checkout is a fairly recent thing.

So with that, the repo update process just becomes:

$ git clean -fdx         # Get rid of untracked ignored files
$ git reset --hard HEAD  # Git rid of tracked modified files
$ git fetch
$ git checkout -B <branch> --track origin/<branch> # Handle branch change and forced push of tracking brach

The above sequence seems to update ORIG_HEAD correctly. Here is a scenario with the Trilinos git repo ...

First, put the repo into a state where it will move HEAD forward by pulling new commits.

$ git log --oneline -1 github/develop
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -3 HEAD
ca90ac0 Tempus: Cleanup ParameterLists
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon
8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git reset --hard HEAD^^
HEAD is now at 8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git log --oneline -1 ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 HEAD
8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

So I have setup 'HEAD'='develop' as two commits behind 'github/develop'

What that shows is that ORIG_HEAD is just pointing to the last place that HEAD was pointing. This corespeonds to HEAD@{1} in git reflog:

$ git reflog -3
8eb026f HEAD@{0}: reset: moving to HEAD^^
ca90ac0 HEAD@{1}: checkout: moving from develop to develop
ca90ac0 HEAD@{2}: checkout: moving from develop to develop

So what about the command git checkout -B <branch> --track origin/<branch>? Does it move HEAD? It has to, right? Lets simulate and update using the above git reset, fetch, checkout:

$ git reset --hard HEAD
HEAD is now at 8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git log --oneline -1 HEAD
8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git log --oneline -1 ORIG_HEAD
8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git checkout -B develop --track github/develop
Branch develop set up to track remote branch develop from github.
Reset branch 'develop'
Your branch is up-to-date with 'github/develop'.

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
8eb026f Fetch and merge in branch on remote before running checkin-test-sems.sh (#482)

$ git log --oneline HEAD ^ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

Okay, so that simulated update of the repo resulted in the correct ORIG_HEAD which will give the right comparison for the later git diff --name-only ORIG_HEAD..HEAD command used in the code to get the udpated files.

Now let's simulate the next update, except this time where no new commits are pulled:

$ git reset --hard HEAD
HEAD is now at ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline HEAD ^ORIG_HEAD
[empty]

$ git checkout -B develop --track github/develop
Branch develop set up to track remote branch develop from github.
Reset branch 'develop'
Your branch is up-to-date with 'github/develop'.

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline HEAD ^ORIG_HEAD
[empty]

So that is interesting. The git reset --hard HEAD command not only gets rid of modified tracked files, it also resets ORIG_HEAD to the current commit. The end result is that HEAD==ORIG_HEAD after the update where no commits were fetched from the remote.

Now let's simulate where a new branch is checked out. Let's say we were on the 'master' branch (which is always behind 'develop') and we switch to the 'develop' branch. What does that update look like?

$ git log --oneline github/develop ^github/master | wc -l
50

$ git checkout --track github/master
Branch master set up to track remote branch master from github.
Switched to a new branch 'master'

$ git log --oneline -1 HEAD
4bfc9e9 Tpetra: Remove use of nondefault node instance from Bug5978 test

$ git log --oneline -1 ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

So we moved back 50 commits (that is how far github/master is behind github/develop right now).

Now let's simulate the switch over from the 'master' to the 'develop' branch:

$ git reset --hard HEAD
HEAD is now at 4bfc9e9 Tpetra: Remove use of nondefault node instance from Bug5978 test

$ git log --oneline -1 HEAD
4bfc9e9 Tpetra: Remove use of nondefault node instance from Bug5978 test

$ git log --oneline -1 ORIG_HEAD
4bfc9e9 Tpetra: Remove use of nondefault node instance from Bug5978 test

$ git checkout -B develop --track github/develop
Branch develop set up to track remote branch develop from github.
Switched to and reset branch 'develop'
Your branch is up-to-date with 'github/develop'.

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
4bfc9e9 Tpetra: Remove use of nondefault node instance from Bug5978 test

$ git log --oneline HEAD ^ORIG_HEAD | wc -l
50

So that worked as well. This will consider the commits and changed files for the updated branch.

Now lets simulate being on a detached head state to some older commit where someone was playing around. Let's go back one commit:

$ git checkout HEAD^
Note: checking out 'HEAD^'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at a7533cd... Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

Now for the simulated update when the automated ctest -S script runs on this repo:

$ git reset --hard HEAD
HEAD is now at a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git checkout -B develop --track github/develop
Previous HEAD position was a7533cd... Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon
Branch develop set up to track remote branch develop from github.
Switched to and reset branch 'develop'
Your branch is up-to-date with 'github/develop'.

$ git log --oneline HEAD ^ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

So in this case, the TribitsCTestDriverCore.cmake code would think changes were w.r.t. the detached head state, not the last time it ran. But that is pretty harmess.

The last question to answer is what to do about the base git repo where CTest does the update for you? From looking at the existing code in TribitsCTestDriverCore.cmake, it looks like it leaves ORIG_HEAD in the correct state so that if you look at git log HEAD ^ORIG_HEAD you will see the updated commits from the last time it ran. If that was not the case, then the set of updated files in the macro TRIBITS_GET_MODIFIED_FILES() would not return the right set of files for the base repo.

Therefore, since the base repo is updated by CTest, when we switch to the right branch, we can't run git reset --hard HEAD, because it would reset ORIG_HEAD to the current updated commit and it would mess everything up. Therefore, for the base repo, the way we should adjust to a the chosen branch is to just run:

$ git checkout -B <branch> --track origin/<branch>

and that is it. In that case, if the branch was changed, then ORIG_HEAD would point back to the commit before the pull. Therefore, git log HEAD ^ORIG_HEAD would show all of the commits (and changes) for before the script ran before the fetch. This would be correct.

Now, the last thing to consider is what to do when ${PROJECT_NAME}_BRANCH is empty? The current implementation in the function EXTRAREPO_CLEAN_FETCH_RESET() is to do:

$ git clean -fdx           # Get rid of untracked ignored files
$ git reset --hard HEAD    # Git rid of tracked modified files
$ git fetch
$ git reset --hard @{u}    # Handle forced push of tracking branch

But does that not reset ORIG_HEAD so that we don't report the right set of updated commmits for the update? Let's try that scenario:

$ git reset --hard HEAD^
HEAD is now at a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git reset --hard HEAD
HEAD is now at a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git log --oneline -1 HEAD
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git log --oneline -1 ORIG_HEAD
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git reset --hard @{u}
HEAD is now at ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
a7533cd Trilinos: removing symbolic links to DrekarBase DrekarResearch tcad-charon

$ git log --oneline HEAD ^ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

So that is interesting. When you call git reset --hard HEAD, it resets ORIG_HEAD to the current HEAD. But when you call git reset --hard @{u} where it changes the HEAD, it leaves ORIG_HEAD along at its current value. That is very strange. Now what happens when you call git reset --hard @{u} where there are no updated commits?

$ git reset --hard @{u}
HEAD is now at ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline -1 ORIG_HEAD
ca90ac0 Tempus: Cleanup ParameterLists

$ git log --oneline HEAD ^ORIG_HEAD
[empty]

So that is interesting. When you call git reset --hard @{u} where it does not move HEAD, it does not move ORIG_HEAD. It seems that is documented behavior:

• https://git-scm.com/docs/git-reset

which says: ""reset" copies the old head to .git/ORIG_HEAD". So if HEAD does not move, then HEAD==ORIG_HEAD when it completes.

What is interesting is that ORIG_HEAD is never even mentioned in the documentation for git checkout as shown at:

• https://git-scm.com/docs/git-checkout

I guess that means that ORIG_HEAD will never be moved by a git checkout command?

So that gives the final set of git commands to run for the different cases:

• Update the base repo:

  • Let CTest update the base repo by calling ctest_update()
  • If ${PROJECT_NAME}_BRANCH is set:
  • git checkout -B ${${PROJECT_NAME}_BRANCH} --track origin/${${PROJECT_NAME}_BRANCH}

• For each extra repo:

  • git clean -fdx # Remove untracked ignored files
  • git reset --hard HEAD # Remove untracked files and modified tracked files
  • git fetch
  • If ${PROJECT_NAME}_BRANCH is set:
  • git checkout -B ${${PROJECT_NAME}_BRANCH} --track origin/${${PROJECT_NAME}_BRANCH}
  • Else:
  • git reset --hard @{u} # Deal with force push

This algorithm will allow git log HEAD ^ORIG_HEAD to proived the best context.

Then I will replace the current mixed in logic that constructs the Updates.txt file one repo at a time with a simple call to:

$ gitdist --dist-no-color log-short --name-status ORIG_HEAD..HEAD

I think this will results fairly minimal changes to the existing code.

A.2) What type of automated testing already exists and how can I add to it?

I know that there is some automated testing. I just need to dig into it some and see what is going on with that. I will try the easy way which is to break the code that I want to change and see what tests fail.

I broke the code in the file TribitsUpdateExtraRepo.cmake in the function EXTRAREPO_CLEAN_FETCH_RESET() by commenting out a git command and the only test that was broken was TriBITS_CTestDriver_CI_EnableAllSecondaryTested_EnableStalix. It looks like I have not created any special unit tests for these. I only grep for the git command (and I don't even check for the order of the git commands).

A.4) How to I validate that it works once I am finished?

I think I can use a subset of CASL VERA repos like say just TriBITS, Trilinos, TeuchosWrappersExt, COBRA-TF that have a 'nightly' branch already and test these various repo operations. I can run a mock CI server for a few iterations.

ToDo:

• Copy the git repo command related tests from TriBITS_CTestDriver_CI_EnableAllSecondaryTested_EnableStalix to its own dedicated test for the repo updates command. [Done]

• Change the name of the function EXTRAREPO_CLEAN_FETCH_RESET() to TRIBITS_UPDATE_GIT_EXTRAREPO() and updates and checkout the right branch for a given repo. [Done]

• Update code in TRIBITS_CLONE_OR_UPDATE_EXTRAREPO() to call TRIBITS_UPDATE_GIT_EXTRAREPO() even after the initial clone. This will put the repo on the right branch and will set ORIG_HEAD so that git log ORIG_HEAD..HEAD will work. [Done]

• Change the name of CLONE_OR_UPDATE_ALL_EXTRAREPOS() to TRIBITS_CLONE_OR_UPDATE_REPOS() and change the name of CLONE_OR_UPDATE_EXTRAREPO() to TRIBITS_CLONE_OR_UPDATE_EXTRAREPO(). Move in code that does the update of the banch of the base git repo [Done]

• Add unit test for checkout out branch ${PROJECT_NAME}_BRANCH for all repos. [Done]

• Create a new var ${PROJECT_NAME}_EXTRAREPOS_BRANCH to be used for the extra repos that will default to ${PROJECT_NAME}_BRANCH. (Trilinos will set this to master for now since the other repos don't have a 'develop' branch yet.) Add unit test for ${PROJECT_NAME}_EXTRAREPOS_BRANCH different from ${PROJECT_NAME}_BRANCH. [Done]

• Create function TRIBITS_CREATE_REPO_UPDATES_FILE() that will create an Updates.txt file using gitdist --dist-no-color log "--pretty=format:%h: %s%nAuthor: %an <%ae>%nDate: %ad%n" --name-status -C ORIG_HEAD..HEAD. Only call this function if the base git repo already existed before calling CTEST_UPDATE(). [Done]

• Only attach the Updates.txt file if it is created. [Done]

• Attach <Project>RepoVersion.txt file (if it exists after doing the first configure) as a notes file. [Done]

• Do some validation tests for a few VERA repos fresh from clone and rerunning for cloned repos that does the update ... That went perfect. See https://vminfo.casl.gov/trac/casl_phi_kanban/ticket/4787#comment:14 [Done]

• Move all support code for TribitsCTestDriverCore.cmake to TribitsCTestDriverCoreHelpers.cmake and update the documentation for TRIBITS_CTEST_DRIVER(). [Done]

• Push to VERA casl-dev/master and set VERA_BRANCH to 'nightly' for nightly testing and 'master' for CI testing [Done]

• Push to TriBITS github/master ... There are merge conflicts that I am going to need to resolve! This is a mess. I need to sync up the casl-dev/master and github/master branches ASAP before I go any further! [Done]

• Snapshot to Trilinos and update Trilinos [Done]

[bartlettroscoe]

Darn, this broke the CASL VERA CI server (and I think will break the nightly builds when they try to run tomorrow). The outer ctest -S script showed the error:

B) Update /localhome/casl-vri-admin/VERACIDashboardsGcc483/VERA ...
      CTEST_UPDATE_COMMAND='/projects/vera/common_tools/git-2.6.4/bin/git'
      CTEST_UPDATE_TYPE='git'
Pull extra updates in '/localhome/casl-vri-admin/VERACIDashboardsGcc483/VERA/TriBITS' ...
CMake Error at VERA/TriBITS/tribits/dashboard_driver/TribitsDriverDashboard.cmake:256 (EXTRAREPO_CLEAN_FETCH_RESET):
  Unknown CMake command "EXTRAREPO_CLEAN_FETCH_RESET".

  Runtime for command = 0.008522 minutes
ctestRtn: '255'
error: ctest returned non-zero error value, script will exit with 255

Darn, since the TDD system is not under automated test, I totally missed this. I thought I looked for that file and function but I somehow missed that.

I wish this old TDD system could just go away. I would really like to write a much simpler version of this so that we can still use CTest and CDash to drive and report these builds.

[bartlettroscoe]

Okay, I think I have this fixed now with this simple commit:

commit a25f931aa662a9e5800924b3ae2beabbdaf2650e
Author: Roscoe A. Bartlett <rabartl@sandia.gov>
Date:   Thu Apr 6 20:38:42 2017 -0400

    Update TDD system for renamed func TRIBITS_UPDATE_GIT_EXTRAREPO() (#130)

    I forgot to update the TDD system for my changes for #130.  Since the TDD
    system is not under automated testing, this was allowed to be pushed.  I was
    slopping in not finding this reference to the old function name.  Sloppy on my
    part.

M       tribits/dashboard_driver/TribitsDriverDashboard.cmake

This CASL VERA CI server is running again after doing a manual update and restart. This would never have fixed itself because the fixing commits needed to be pulled for TriBITS and that pull was broken :-( Therefore, I had to manually update the other nightly testing driver dirs. Therefore, they should run fine tomorrow as well.

Note that this would not break any of the Trilinos TDD driver invocations because it does not clone and update a separate TriBITS repo.

I will put this back in review and see how things go from here.

[bartlettroscoe]

This has been running smoothly for VERA and Trilinos for some time now. Closing as complete.