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

Created on 23 Feb 2018  路  3Comments  路  Source: trilinos/Trilinos

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

Framework tasks question

Most helpful comment

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?

All 3 comments

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?

@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?

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 [email protected]: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?

Was this page helpful?
0 / 5 - 0 ratings