MOOSE-Based Application Development on GitLab

Similar documents
Github/Git Primer. Tyler Hague

A BASIC UNDERSTANDING OF VERSION CONTROL

Outline The three W s Overview of gits structure Using git Final stuff. Git. A fast distributed revision control system

Introduction to Git. Database Systems DataLab, CS, NTHU Spring, 2018

Git. A fast distributed revision control system. Nils Moschüring PhD Student (LMU)

Topics covered. Introduction to Git Git workflows Git key concepts Hands on session Branching models. Git 2

GIT Princípy tvorby softvéru, FMFI UK Jana Kostičová,

git commit --amend git rebase <base> git reflog git checkout -b Create and check out a new branch named <branch>. Drop the -b

CS 390 Software Engineering Lecture 5 More Git

Getting the files for the first time...2. Making Changes, Commiting them and Pull Requests:...5. Update your repository from the upstream master...

GUIDE TO MAKE A REAL CONTRIBUTION TO AN OPEN SOURCE PROJECT 1. 1

Lab 01 How to Survive & Introduction to Git. Web Programming DataLab, CS, NTHU

Git. Charles J. Geyer School of Statistics University of Minnesota. Stat 8054 Lecture Notes

Software Development I

Managing Network Configurations with Git and GitLab

Beyond git add/commit/push

Git(Lab) Tutorial and Hands-On

Version Control System - Git. zswu

Git. Presenter: Haotao (Eric) Lai Contact:

Git for Subversion users

Submitting your Work using GIT

Git. SSE2034: System Software Experiment 3, Fall 2018, Jinkyu Jeong

From Tiny Acorns Your first submission to OpenAFS. Simon Wilkinson

GIT. A free and open source distributed version control system. User Guide. January, Department of Computer Science and Engineering

Using GitHub and SourceTree to work with DITA TC repositories

1. Git. Robert Snapp

Git Tutorial. André Sailer. ILD Technical Meeting April 24, 2017 CERN-EP-LCD. ILD Technical Meeting, Apr 24, 2017 A. Sailer: Git Tutorial 1/36

Git Workflows. Sylvain Bouveret, Grégory Mounié, Matthieu Moy

Creating a Patch. Created by Carl Heymann on 2010 Sep 14 1

Assumptions. GIT Commands. OS Commands

git Version: 2.0b Merge combines trees, and checks out the result Pull does a fetch, then a merge If you only can remember one command:

Revision control. INF5750/ Lecture 2 (Part I)

Git tips. Some tips to use Git.

Revision Control and GIT

API RI. Application Programming Interface Reference Implementation. Policies and Procedures Discussion

Index. Alias syntax, 31 Author and commit attributes, 334

Tutorial 2 GitHub Tutorial

Tips on how to set up a GitHub account:

FAQ Q: Where/in which branch do I create new code/modify existing code? A: Q: How do I commit new changes? A:

Software Revision Control for MASS. Git Installation / Configuration / Use

KTH Royal Institute of Technology SEMINAR 2-29 March Simone Stefani -

2 Initialize a git repository on your machine, add a README file, commit and push

CS314 Software Engineering Configuration Management

Version Control: Gitting Started

Introduction to Version Control

Revision Control. An Introduction Using Git 1/15

RSARTE Git Integration

G E T T I N G S TA R T E D W I T H G I T

FEEG Applied Programming 3 - Version Control and Git II

CS 520: VCS and Git. Intermediate Topics Ben Kushigian

Git tutorial. Katie Osterried C2SM. October 22, 2015

Version Control. Version Control

Introduction to Git and Github

Git. A Distributed Version Control System. Carlos García Campos

Advanced Operating Systems Control Versioning with GIT. Giuseppe Massari

Versioning with git. Moritz August Git/Bash/Python-Course for MPE. Moritz August Versioning with Git

Working in Teams CS 520 Theory and Practice of Software Engineering Fall 2018

Object Oriented Programming. Week 1 Part 2 Git and egit

VCS VERSION CONTROL SYSTEMS

Gitting things done. Hands-on introduction to git niceties. Jan Urbański Ducksboard

Version Control. Second level Third level Fourth level Fifth level. - Software Development Project. January 11, 2017

Lab Objective. Lab Assignment. Downloads and Installation

Getting the Source Code

Git & Github Fundamental by Rajesh Kumar.

Git Introduction CS 400. February 11, 2018

Version Control with GIT

Tizen/Artik IoT Practice Part 4 Open Source Development

Django MFA Documentation

Code and data management with Git

Windows. Everywhere else

Gitlab Setup/Usage by Yifeng Zhu modified by Vince Weaver 30 January 2019

Distributed Version Control (with Git)

LPF Training Handbook!

Software configuration management

What is version control? (discuss) Who has used version control? Favorite VCS? Uses of version control (read)

Common Git Commands. Git Crash Course. Teon Banek April 7, Teon Banek (TakeLab) Common Git Commands TakeLab 1 / 18

What is git? Distributed Version Control System (VCS); Created by Linus Torvalds, to help with Linux development;

Version Control Systems (VCS)

February 2 nd Jean Parpaillon

Visualizing Git Workflows. A visual guide to 539 workflows

GIT. CS 490MT/5555, Spring 2017, Yongjie Zheng

Git: Distributed Version Control

Version Control. Version Control

Git better. Collaborative project management using Git and GitHub. Matteo Sostero March 13, Sant Anna School of Advanced Studies

About the Tutorial. Audience. Prerequisites. Copyright & Disclaimer. Gerrit

USING GIT FOR AUTOMATION AND COLLABORATION JUSTIN ELLIOTT - MATT HANSEN PENN STATE UNIVERSITY

GETTING TO KNOW GIT: PART II JUSTIN ELLIOTT PENN STATE UNIVERSITY

Git: Distributed Version Control

Improving Your Life With Git

Git version control with Eclipse (EGit) Tutorial

Computer Science Design I Version Control with Git

Version Control with Git

1. Which of these Git client commands creates a copy of the repository and a working directory in the client s workspace. (Choose one.

Git Basi, workflow e concetti avanzati (pt2)

Introduction to Version Control with Git

License. Introduction to Version Control with Git. Local Version Control Systems. Why Use Version Control?

A Brief Git Primer for CS 350

How to be a git. Dominic Mitchell

(Cloud9) and to the Remote Repository (GitHub)

1/20/13 Git tutorial. Git tutorial. Mike Nolta. file:///users/nolta/github/reveal.js/git.html?print-paper#/ 1/31

Transcription:

MOOSE-Based Application Development on GitLab MOOSE Team Idaho National Laboratory February 22, 2016

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: https://mooseframework.org/static/media/uploads/docs/moose_github.pdf

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. We will issue all commands in a separate terminal as we go. Please ask questions at any time!

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: http://tinyurl.com/lyrh69p

Introduction We will refer back to this figure several times... GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

Introduction Primary application repository = upstream GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

Introduction Your personal fork of the application repository = origin GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

Introduction The git clone of your fork = /projects/<appname> GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

Setup 1 Introduction 2 Setup 3 Workflow

Setup Step 1: Network, Firewall pass-through setup 1 Setup the connection the hpcgitlab.inl.gov using SOCKS. Edit ~/.ssh/config and make sure you have the following: Host hpcgitlab.inl.gov User <your HPC username here> ProxyCommand nc -x localhost:5555 %h %p 2 Open a secure connection to hpclogin and create a SOCKS proxy $ ssh -D 5555 hpclogin.inl.gov 3 Setup your browser to use SOCKS proxy hostname: localhost port: 5555 4 Vist https://hpcgitlab.inl.gov Note: You will need to uncheck those proxy settings in your browser when you terminate your ssh session.

Setup Step 2: Fork the application repository 1 Go to https://hpcgitlab.inl.gov/idaholab/<appname> 2 Click the Fork repository button.

Setup Step 3: 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: idaholab/<appname>

Setup Step 3: Make a clone of your fork 3 Copy the SSH URL, you will use it momentarily...

Setup Step 3: Make a clone of your fork 4 Go to a terminal. 5 $ cd ~/projects 6 $ git clone git@hpcgitlab.inl.gov:username/<appname>.git 7 $ cd <appname> 8 $ git config user.name "Your Name" 9 $ git config user.email your email@inl.gov

Setup Step 4: Add a remote for the upstream application repository $ git remote add upstream git@hpcgitlab.inl.gov: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. The name origin refers to your personal fork of the application repository.

Setup Step 5: Give other users access to your fork Click Settings

Setup Step 5: Give other users access to your fork Click Members

Setup Step 5: Give other users access to your fork Click Import members

Setup Step 5: Give other users access to your fork Choose the appropriate upstream project

Setup Summary 1 Fork the application repository. 2 Make a clone of your fork. 3 Add a remote for the upstream application repository. 4 Give other users access to your fork.

Workflow 1 Introduction 2 Setup 3 Workflow

Workflow Step 0: Create or pick an issue Visit https://hpcgitlab.inl.gov/idaholab/<appname> Click the green menu button in the top right and select New Issue

Workflow Step 0: Create or pick an issue Enter a title, brief description, and labels for the issue, then click the Submit new issue button.

Workflow Step 1: Pull down the latest changes from upstream Change directories to where you cloned your fork, and run: $ git fetch upstream $ git checkout devel $ git rebase upstream/devel Avoid using git pull commands: Merge commits without proper flags Always do this before starting work to ensure you are up to date.

Workflow Step 1: Pull down the latest changes from upstream GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

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. Please don t use the word feature when naming your branch!

Workflow Step 2: Create a new branch for your work GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

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: $ git commit -a -m"some message which mentions #1729."

Workflow Step 3: Add, modify, and commit code to address the issue GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

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 fetch upstream $ git 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. You can also easily share work between different computers you own using GitLab.

Workflow Step 4: Push your work up to your fork GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

Workflow Step 4: Push your work up to your fork The Network shows your commits in relation to others.

Workflow Step 5: Create a Merge Request on GitLab Once your branch is ready to be merged, you can alert other developers by creating a Merge Request.

Workflow Step 5: Create a Merge Request on GitLab Your merge request should be made on your project s devel branch (not master).

Workflow Step 5: Create a Merge Request on GitLab GitLab (hpcgitlab.inl.gov) upstream master devel devel review, test, merge Idaholab/<appname> git fetch upstream 1 git checkout devel [ git rebase upstream/devel ] 3 git add [ git commit ] origin 5 Pull Request feature_1729 2 [ git checkout b feature_1729 devel ] username/<appname> feature_1729 4 [ git push origin feature_1729 ] ~/projects/<appname>

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). As a workaround, simply edit the Merge Request description to trigger moosebuild to re-test.

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: $ git push -f origin feature_1729

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. 6 Monitor and respond to comments on your merge request.