Commit 51ff7f5c authored by French, Robert's avatar French, Robert
Browse files

Use Marp for presentations

parent 544f3207
### Jan 26: Continuous Integration with Gitlab Runners
<!-- $theme: default -->
<!-- page_number: true -->
# Continuous Integration with Gitlab Runners
**Thursday 1/26, 9:00am in JICS Auditorium (5100 RM 128)**
Continuous Integration is all the rage for producing high-quality software.
Gitlab provides a tool called "Runners" that allow you to automatically run your
test suite every time new code is pushed. This makes it very easy to sanity
check new Merge Requests before they get accepted -- this is a great (but not
perfect) line of defense for keeping bugs out of your code.
* Continuous Integration is all the rage for producing high-quality software.
* Gitlab provides a tool called "Runners" that allow you to automatically run your test suite every time new code is pushed.
* This makes it very easy to sanity check new Merge Requests before they get accepted -- this is a great (but not perfect) line of defense for keeping bugs out of your code.
* We'll talk about how to set up gitlab runners on your desktop, and define a simple "pipeline" that tells Gitlab what to do when new code is pushed.
---
We'll talk about how to set up gitlab runners on your desktop, and define a
simple "pipeline" that tells Gitlab what to do when new code is pushed.
# Continuous Integration with Gitlab Runners
## A simple pipeline for testing
## Some Definitions
* **Pipeline** - a set of batch jobs which must succeed for your push to get a green checkmark.
* **Build** - This should have been "Job" or "Batch Job". You can use it to build code, or to test an existing build, or to deploy a build, or email positive affirmations to yourself. Up to you.
### How to get a Green Light
---
# Continuous Integration with Gitlab Runners
## How to get a Green Light
1. If a build fails, then the whole pipeline fails.
1. If a pipeline fails, then your push gets a red X.
1. Otherwise you get a Green Light.
Let's look at the [pipeline definition]() from the [Inspirational Quote Generator](https://code.ornl.gov/git-it-together/inspirational-quote-generator).
### Configuring runners in your project
---
# Continuous Integration with Gitlab Runners
## Configuring runners in your project
* I will walk through configuring a new runner on my Fedora Linux desktop unless I get bitten by the Live Demo gremlins.
* For posterity, I am mostly just implementing the official guidance from GitLab available [here](https://docs.gitlab.com/ee/ci/runners/README.html#creating-and-registering-a-runner).
---
# Continuous Integration with Gitlab Runners
## Testing on multiple platforms
I will walk through configuring a new runner on my Fedora Linux desktop unless I get bitten by the Live Demo gremlins. For posterity, I am mostly just implementing the official guidance from GitLab: https://docs.gitlab.com/ee/ci/runners/README.html#creating-and-registering-a-runner
* If the above runner was configured successfully, *and* we add a new build definition to our pipeline, we will be able to test our application simultaneously on both Mac OS X and Redhat Linux.
* You can image going crazy with this -- testing on Crays, embedded systems, even (dare I say?) Windows.
### Testing on multiple platforms
---
If the above runner was configured successfully, *and* we add a new build definition to our pipeline, we will be able to test our application simultaneously on both Mac OS X and Redhat Linux. You can image going crazy with this -- testing on Crays, embedded systems, even (dare I say?) Windows.
# Continuous Integration with Gitlab Runners
## Pro Tip: Force Merge Requests to pass Tests
At this point I will show how to configure your GitLab repo so that Merge Requests must pass before they can be merged -- this can help you enforce quality control in your project, and is arguably the most useful aspect of Continuous Integration.
---
# Continuous Integration with Gitlab Runners
### Double Pro Tip Bonus: Protect Master from Pushes
You can further protect your repo from un-tested code by removing everyone's ability to push directly to master. This means that all changes must be submitted as Merge Requests. This may be a bit more obnoxious, especially for single person projects, but it ensures that nothing can get into master without passing CI first. See GitLab's [Docs on Protected Branches](https://docs.gitlab.com/ee/user/project/protected_branches.html)
---
# Continuous Integration with Gitlab Runners
## But wait there's more!
* Automatically build executables for different platforms
* Deploy new versions of your software with every commit to master (Continuous Delivery)
* **Run Simulations in Response to code updates!**
---
# Continuous Integration with Gitlab Runners
## Questions?
---
# Git It Together!
## Other Important Business
* Everyone join [ORNL's Slack](ornl.slack.com) and hang out in the `#git` channel!
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment