Can the checkin script be used to test/push a branch to fork of Trilinos

[jhux2]

Question: Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?

Context
I would like to use the checkin script to test changes in a local branch within my fork of Trilinos. If all tests pass, ideally the script would then automatically push the branch to my fork. After that, I would issue a pull request against trilinos/Trilinos.

@trilinos/framework @bartlettroscoe

[bartlettroscoe]

Can the checkin script be used to test and push a branch on a fork of Trilinos, and if so, what's the procedure for setting this up?

The simple answer is yes. It is just that you might need to write a little script to call the checkin-test-sems.sh script in this case. I can write up a little wiki howto on the Trilinos GitHub wiki if you would be willing to review it.

Sound good?

[lucbv]

@jhux2, I think that if your local branch is already tracking a remote branch on your personal fork then it probably does what you want.
@bartlettroscoe: it would be nice to have the checkin script automatically create the remote branch on the fork when asked to do --push, maybe with a flag like --push-upstream?

[bartlettroscoe]

I think that if your local branch is already tracking a remote branch on your personal fork then it probably does what you want.

The checkin-test.py script will always push to whatever the remote tracking branch is. But it will be comparing changes in HEAD to that tracking branch, which is not what you want in a topic branch workflow. Instead, what you want is to compare the changes in HEAD in your topic branch to the GithHub trilinos/Trilinos develop branch. Therefore, to do the property testing, for now, you will just need to manually select which packages to test such as with:

$ ./checkin-test-sems.sh --enable-packages=MueLu --do-all --push

To set this up, you just need to be on your topic branch and it must be pointing to a tracking branch in your fork of Trilinos. For example, you can set this up with:

$ cd Trilinos/
[    (<branch>)]$ git checkout develop
[     (develop)]$ git pull   # Assume 'develop' is clean here
[     (develop)]$ git checkout -b 1234-topic-a
[(1234-topic-a))$ git push -u <your-github-fork> 1234-topic-a

Then you can add commits to your topic branch as you like and run checkin-test-sems.sh (or your own customized checkin-test.py driver) as above by setting --enable-packages=<packages-you-are-changing> to push to your fork. If if you use --rebase, it will rebase any non-fwd local commits onto that topic branch in case you are collaborating with someone on it.

But to make this more automatic, I am adding the option --compare-to=<remote>:<branch> (see TriBITSPub/TriBITS#251) so that you can run:

$ ./checkin-test-sems.sh --compare-to=upstream:develop --do-all --push

(assuming upstream is a remote name for git@github.com:trilinos/Trilinos.git) and it will automatically compare to what is in HEAD to the main develop branch and therefore test everything that is changed compared to that.

Is having to manually set --enable-packages=MueLu for now good enough or do you want to wait for the option --compare-to to be implemented and deployed?

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[github-actions]

This issue was closed due to inactivity for 395 days.