Commit 14c26be8 authored by French, Robert's avatar French, Robert
Browse files

Done

parent 831f6be3
......@@ -9,3 +9,45 @@ 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.
## A simple pipeline for testing
* **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
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
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
### 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.
## 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.
### 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)
## 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!**
## Questions?
## Other Important Business
* Everyone join [ORNL's Slack](ornl.slack.com) and hang out in the `#git` channel!
* Going to send out a survey to make sure these talks are meeting everyones' needs
* Take a look at the [Suggested Topics List](https://code.ornl.gov/git-it-together/meetings/issues?label_name%5B%5D=topic-suggestion) and sign up for any that you would feel comfortable speaking on! If you have an idea for a topic suggestion, please post it there, but be ready to scratch your own itch if no one knows about your topic already -- want to everyone to feel able to share!
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