Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
M
MicroCART
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Deploy
Releases
Model registry
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Distributed Autonomous Networked Control Lab
MicroCART
Commits
abcf9304
Commit
abcf9304
authored
7 years ago
by
bbartels
Browse files
Options
Downloads
Patches
Plain Diff
documentation: add CI FAQ
parent
c2134927
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
documentation/ci_faq.md
+40
-0
40 additions, 0 deletions
documentation/ci_faq.md
with
40 additions
and
0 deletions
documentation/ci_faq.md
0 → 100644
+
40
−
0
View file @
abcf9304
# Continuous Integration (CI) FAQ
## Why did my commit fail CI?
On every commit, a script runs that performs a number of things, including
compiling code and running unit and functional tests. Whatever you did
apparently broke one of these things.
## Why should I care about the CI results?
CI _immensely_ streamlines the development cycle by helping us catch bugs
immediately, allowing us to fix them early before they plague us (or future
users of the code base). It's a common industry practice. If you break the CI
pipeline, don't ignore it! Try your best to get the branch back in working
condition.
## Okay, so my commit failed CI, and I guess I care. What should I do?
1.
Re-run the build.
-
Sometimes something weird happens, so it's good to check this.
2.
Figure out what you did wrong and fix it.
-
If you click on the build, you should be able to see the exact logs the
build process. Debug the error to figure out what went wrong. Maybe you
failed a test. You may need to open the source code for the test to see
where you failed, which is very insightful into figuring out what went
wrong.
3.
Figure out what CI is doing wrong.
-
Sometimes a test might be poorly designed. At this point, it can be really
tempting to just ignore the build failure altogether (don't do that!), or
just remove the broken test (not as bad, but still don't do that). The best
thing is to fix the test so that we continue to have good regression
test coverage over our code.
## How does CI work?
When a commit is added to a branch in our repository, a notification is sent out
to our gitlab-ci-runner, which instructs it to checkout the updated branch and
run the directive in
`.gitlab-ci.yml`
. It then runs each directive, which is
made up of bash scripts to execute. In our case, we run two scripts,
`ci-build.sh`
and
`ci-test.sh`
, which compile projects and run checks,
respectively. (Look at these scripts to learn more about how they work). If
some error occurs during the script (perhaps a forced error generated by a
failed test), then the runner sends a message back to Gitlab indicating that the
CI failed. Otherwise, it succeeds.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment