MOOSE-Based Application Development on GitLab

(1)

MOOSE-Based Application Development on

GitLab

MOOSE Team Idaho National Laboratory

(2)

Introduction

The intended audience for this talk is developers of INL-hosted, MOOSE-based applications.

For information on contributing to the MOOSE framework itself, please see:

(3)

Introduction

This talk is divided into the following sections:

Setup – Commands you run one time, when getting started. Workflow – Commands you’ll run every time you develop on GitLab.

(4)

Introduction

This talk assumes you:

Have access to the INL HPC enclave, and can browse to https://hpcgitlab.inl.gov/groups/idaholab Have uploaded your public SSH key to GitLab, for help on this, please see:

(5)

Introduction

We will refer back to this figure several times. . .

upstream

origin

GitLab (hpcgitlab.inl.gov) idaholab/<appname> ~/projects/<appname> master devel devel feature_1729

git checkout devel git pull –-‐rebase upstream devel

[

]

git checkout –b feature_1729 devel

[ ] git add git commit

[

]

username/<appname> feature_1729

git push origin feature_1729

[ ]

Pull Request

review, test, merge

1

2 3

(6)

Introduction

Primary application repository = “upstream”

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(7)

Introduction

Your personal fork of the application repository = “origin”

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(8)

Introduction

The git clone of your fork = “∼/projects/<appname>”

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(9)

Setup

1 Introduction 2 Setup

(10)

Setup

Step 1: Fork the application repository

1 Go to https://hpcgitlab.inl.gov/idaholab/<appname>

(11)

Setup

Step 2: Make a clone of your fork

1 Go to your fork,https://hpcgitlab.inl.gov/username/<appname>

2 On the right side, it should say: “Forked from:

(12)

Setup

(13)

Setup

4 Go to a terminal.

5 $ cd ~/projects

6 $ git clone [email protected]:username/<appname>.git

7 $ cd <appname>

8 $ git config user.name "Your Name"

(14)

Setup

Step 3: Add a remote for the upstream application repository

$ git remote add upstream [email protected]:idaholab/<appname>.git

Adding a remote allows you to stay up-to-date with changes to your application.

The name “upstream” is standard in git parlance, it refers to the “central” repository for your application.

(15)

Setup

Step 4: Give other users access to your fork

(16)

Setup

(17)

Setup

(18)

Setup

(19)

Setup Summary

1 Fork the application repository.

2 Make a clone of your fork.

3 Add a remote for the upstream application repository.

(20)

Workflow

(21)

Workflow

Step 0: Create or pick an issue

Visit https://hpcgitlab.inl.gov/idaholab/<appname>

(22)

Workflow

Step 0: Create or pick an issue

(23)

Workflow

Step 1: Pull down the latest changes from upstream

Change directories to where you cloned your fork, and run: $ git checkout devel

$ git pull --rebase upstream devel

(24)

Workflow

Step 1: Pull down the latest changes from upstream

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(25)

Workflow

Step 2: Create a new branch for your work

Name your branch with your issue number, say #1729. Branch off from devel:

$ git checkout -b feature_1729 devel

In the command above, feature 1729 is the name of the branch being created.

(26)

Workflow

Step 2: Create a new branch for your work

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(27)

Workflow

Step 3: Add, modify, and commit code to address the issue

This step is obviously specific to the problem at hand, but you will frequently use the commands:

1 git add

Add “untracked” files.

2 git status

Print a summary of what’s changed.

3 git checkout

Revert changes to particular files.

4 git diff

Print a detailed view of your changes.

When you are done, commit your changes locally:

(28)

Workflow

Step 3: Add, modify, and commit code to address the issue

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(29)

Workflow

Step 4: Push your work up to your fork

When you are ready to share your work with others, first make sure you are up to date:

$ git pull --rebase upstream devel Make sure the code still compiles and the tests run.

Then push the branch to your fork, which by default is called “origin”:

$ git push origin feature_1729

You (and others!) should now be able to see this new branch, and browse the commits directly on the GitLab site.

(30)

Workflow

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(31)

Workflow

(32)

Workflow

Step 5: Create a Merge Request on GitLab

(33)

Workflow

(34)

Workflow

upstream

origin

[

]

[

]

[ ]

Pull Request

1

2 3

(35)

Workflow

Step 6: Monitor and respond to comments on your merge request

Your merge request will be automatically updated when:

1 The continuous integration system, moosebuild, tests your new code.

2 The application developers make comments.

3 Your code is merged, or your merge request is closed for any reason.

Important: pushing new commits to the Merge Request branch does not trigger moosebuild to re-test your code (we will support this soon).

(36)

Workflow

Step 6: Monitor and respond to comments on your merge request

If you change a commit that has already been pushed to your fork, it’s called “rewriting history”.

Let’s say you want to edit only the most recently pushed commit.

First make all the necessary changes, including adding new files, and then run

$ git commit -a --amend

You will also be able to edit the most recent commit message. This is a good way to add a forgotten issue number!

Push the change up to your fork using the -f flag:

(37)

Workflow Summary

0 Create/decide issue to work on, say #1729.

1 Pull down the latest changes from upstream.

2 Create a branch named feature 1729.

3 Modify code, create new files, etc. to fix the issue.

4 Push your work up to your fork.

5 Create a merge request from your fork into idaholab:devel.