Deploy automated develop to master branch testing

[jwillenbring]

@trilinos/framework

@allevin has completed revisions toward a capability that will allow us to automate the testing of the develop branch to determine if it is safe to promote that version of code to the master branch.

We need to deploy this capability. Here are some proposed tasks for discussion for completion of this story:

1. Fully deploy the capability on Aaron's fork of Trilinos. This will allow us to see the capability in action a couple of times from beginning to end. This should use the complete infrastructure intended for the eventually full deployment, including Jenkins.

2. Test the new capability using the primary Trilinos repository, but temporarily disable the push to master.

3. Fully deploy, including the push to master.

Please comment on this approach.

[lxmota]

Any news on this issue? The develop branch has not been merged into master for a while and that is preventing some work in Albany.

[bartlettroscoe]

Is this not the same issue as #982?

[bartlettroscoe]

Any updates on this?

[jwillenbring]

@allevin has this ready for a test deployment. @bmpersc is working through some entity account issues currently.

[bmpersc]

Currently there are issues with getting the entity account access to the repo for these tools. The proper accounts have been requested, but we still can't access the gitlab site. I have a ticket into the admins for gitlab to help figure out what is going on, but have not heard back yet.

[bartlettroscoe]

The proper accounts have been requested, but we still can't access the gitlab site.

What GitLab site? Is this not going to work against the Trilinos GitHub site?

[bartlettroscoe]

Just curious, but is this an issue for Trilinos customers not having this automated updating from 'develop' to 'master' in place? Does Albany use the 'mater' branch of Trilinos? If so, is not having this automated creating a problem for Albany?

I added this to the SART board just so that it can be mentioned at a SART meeting.

[lxmota]

Yes, it is an issue for Albany users. Not so much for developers.

Albany developers for the most part use Trilinos develop, so there is no issue there.

Albany users for the most part use Trilinos master. The reason is that they are doing production runs, and pulling from Trilinos develop sometimes breaks the Albany build.

The problem is when the master branch lags behind the develop branch for weeks. Relatively frequently, some of us introduce changes into Trilinos due to feature requests, and these features are not available to the users that request them for weeks due to that lag.

As an example, I introduced some changes to Piro and NOX/LOCA to be able to perform concurrent multiscale calculations from microstructure to macroscopic models for Albany/LCM. This was a long-standing feature request that I completed about a week ago. The changes are on develop, but my LCM customers are waiting because they use master. I can't tell them exactly when the features will be available to them because I don't know when a merge from develop to master will occur.

[ibaned]

Another scenario that has happened is that Trilinos master will not compile with some platform/compiler combination required by Albany, and if the merge frequency is low then the users @lxmota mentioned will be stuck unable to compile for weeks.

[bartlettroscoe]

Being that this would help Albany (and likely other users), would anyone shoot me if I implemented an automated 'develop' to 'master' update for now based on the standard post-push CI build:

• https://github.com/trilinos/Trilinos/wiki/Policies--%7C-Testing#post_push_ci_testing

?

I could likely get it done in a couple of hours or so. Basically, the TriBITS ctest -S script that runs the CI build that submits to CDash returns 0 only if everything passes (which is a feature that is unit tested and is used with Travis CI for the TriBITS repo itself, for example). That way, when an update did not occur, you would know why; you could see it right on the standard CI build dashboard:

• https://testing.sandia.gov/cdash/index.php?project=Trilinos&filtercount=3&showfilters=1&filtercombine=and&field1=buildname&compare1=66&value1=-MPI_RELEASE_DEBUG_SHARED_PT_CI&field2=groupname&compare2=61&value2=Continuous&field3=buildstarttime&compare3=84&value3=now

But I would like to do an explicit merge commit from 'develop' to 'master' to allow for backing out a merge if needed and to make it an explicit event that we can see in history, as per the argument in:

• https://docs.google.com/document/d/1uVQYI2cmNx09fDkHDA136yqDTqayhxqfvjFiuUue7wo/edit#heading=h.u2ougk1wk7ph

Let me know (up or down).

[jwillenbring]

@bartlettroscoe This is not in alignment with Trilinos Framework plans. A great deal of time has been invested in this already, but we are resource constrained.

[bartlettroscoe]

This is not in alignment with Trilinos Framework plans. A great deal of time has been invested in this already, but we are resource constrained.

We can turn off the updates that I implement when the Trilinos Framework team deploys its implementation. That is the harm in that approach?

[bartlettroscoe]

Since this is a core framework activity, we need to leave it to the framework team to address this. Sorry to create traffic on this.

[jwillenbring]

Develop->master promotions have been automated for some time.