diff options
| author | Filipe Freire <filipefreire@iopo0640.lan> | 2018-01-16 18:18:48 +0000 |
|---|---|---|
| committer | Filipe Freire <filipefreire@iopo0640.lan> | 2018-01-16 18:18:48 +0000 |
| commit | 2fe03c94037a439d28e3700bac02ca73a0a225f4 (patch) | |
| tree | 685ef188943a9df186dda6b6ba08f633ca61f728 /doc | |
| parent | a1a5d142981379087ca7183d402300a3a3b6ad52 (diff) | |
| parent | 66ae75600af3cdcaf67991b4ae0701d84de2f31a (diff) | |
| download | gitlab-ce-2fe03c94037a439d28e3700bac02ca73a0a225f4.tar.gz | |
Merge branch 'master' of https://gitlab.com/filipefreire/gitlab-ce into filipefreire_155
Diffstat (limited to 'doc')
26 files changed, 918 insertions, 1173 deletions
diff --git a/doc/api/milestones.md b/doc/api/milestones.md index 84930f0bdc9..d35e940d7b1 100644 --- a/doc/api/milestones.md +++ b/doc/api/milestones.md @@ -93,6 +93,19 @@ Parameters: - `start_date` (optional) - The start date of the milestone - `state_event` (optional) - The state event of the milestone (close|activate) +## Delete project milestone + +Only for user with developer access to the project. + +``` +DELETE /projects/:id/milestones/:milestone_id +``` + +Parameters: + +- `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user +- `milestone_id` (required) - The ID of the project's milestone + ## Get all issues assigned to a single milestone Gets all issues assigned to a single project milestone. diff --git a/doc/api/users.md b/doc/api/users.md index 478d747a50d..1da6fcf297d 100644 --- a/doc/api/users.md +++ b/doc/api/users.md @@ -415,6 +415,10 @@ GET /user } ``` +## List user projects + +Please refer to the [List of user projects ](projects.md#list-user-projects). + ## List SSH keys Get a list of currently authenticated user's SSH keys. diff --git a/doc/articles/index.md b/doc/articles/index.md index 8385ef936c6..c1c3ff67328 100644 --- a/doc/articles/index.md +++ b/doc/articles/index.md @@ -1,93 +1,13 @@ -# Technical Articles +# Technical articles list (deprecated) -[Technical Articles](../development/writing_documentation.md#technical-articles) are +[Technical articles](../development/writing_documentation.md#technical-articles) are topic-related documentation, written with an user-friendly approach and language, aiming to provide the community with guidance on specific processes to achieve certain objectives. -They are written by members of the GitLab Team and by -[Community Writers](https://about.gitlab.com/handbook/product/technical-writing/community-writers/). +The list of technical articles was [deprecated](https://gitlab.com/gitlab-org/gitlab-ce/issues/41138) in favor of having them linked from their topic-related documentation: -Part of the articles listed below link to the [GitLab Blog](https://about.gitlab.com/blog/), -where they were originally published. - -## Build, test, and deploy with GitLab CI/CD - -Build, test, and deploy the software you develop with [GitLab CI/CD](../ci/README.md): - -| Article title | Category | Publishing date | -| :------------ | :------: | --------------: | -| [Autoscaling GitLab Runners on AWS](runner_autoscale_aws/index.md) | Admin guide | 2017-11-24 | -| [Making CI Easier with GitLab](https://about.gitlab.com/2017/07/13/making-ci-easier-with-gitlab/) | Concepts | 2017-07-13 | -| [Dockerizing GitLab Review Apps](https://about.gitlab.com/2017/07/11/dockerizing-review-apps/) | Concepts | 2017-07-11 | -| [Continuous Integration: From Jenkins to GitLab Using Docker](https://about.gitlab.com/2017/07/27/docker-my-precious/) | Concepts | 2017-07-27 | -| [Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/) | Tutorial | 2016-12-14 | -| [Setting up GitLab CI for Android projects](https://about.gitlab.com/2016/11/30/setting-up-gitlab-ci-for-android-projects/) | Tutorial | 2016-11-30 | -| [Automated Debian Package Build with GitLab CI](https://about.gitlab.com/2016/10/12/automated-debian-package-build-with-gitlab-ci/) | Tutorial | 2016-10-12 | -| [Building an Elixir Release into a Docker image using GitLab CI](https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/) | Tutorial | 2016-08-11 | -| [Continuous Delivery with GitLab and Convox](https://about.gitlab.com/2016/06/09/continuous-delivery-with-gitlab-and-convox/) | Technical overview | 2016-06-09 | -| [GitLab Container Registry](https://about.gitlab.com/2016/05/23/gitlab-container-registry/) | Technical overview | 2016-05-23 | -| [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/) | Technical overview | 2017-05-15 | -| [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/) | Tutorial | 2016-03-10 | - -## GitLab Pages - -Learn how to deploy a static website with [GitLab Pages](../user/project/pages/index.md#getting-started): - -| Article title | Category | Publishing date | -| :------------ | :------: | --------------: | -| **Series: GitLab Pages from A to Z:** | -| [- Part 1: Static sites and GitLab Pages domains](../user/project/pages/getting_started_part_one.md)| User guide | 2017-02-22 | -| [- Part 2: Quick start guide - Setting up GitLab Pages](../user/project/pages/getting_started_part_two.md)| User guide | 2017-02-22 | -| [- Part 3: Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](../user/project/pages/getting_started_part_three.md)| User guide | 2017-02-22 | -| [- Part 4: Creating and tweaking `.gitlab-ci.yml` for GitLab Pages](../user/project/pages/getting_started_part_four.md)| User guide | 2017-02-22 | -| [Setting up GitLab Pages with CloudFlare Certificates](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/) | Tutorial | 2017-02-07 | -| [Building a new GitLab Docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) | Tutorial | 2016-12-07 | -| [Publish Code Coverage Report with GitLab Pages](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/) | Tutorial | 2016-11-03 | -| [GitLab CI: Deployment & Environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/) | Tutorial | 2016-08-26 | -| [Posting to your GitLab Pages blog from iOS](https://about.gitlab.com/2016/08/19/posting-to-your-gitlab-pages-blog-from-ios/) | Tutorial | 2016-08-19 | -| **Series: Static Site Generator:** | -| [- Part 1: Dynamic vs Static Websites](https://about.gitlab.com/2016/06/03/ssg-overview-gitlab-pages-part-1-dynamic-x-static/) | Tutorial | 2016-06-03 | -| [- Part 2: Modern Static Site Generators](https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/) | Tutorial | 2016-06-10 | -| [- Part 3: Build any SSG site with GitLab Pages](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/) | Tutorial | 2016-06-17 | -| [Securing your GitLab Pages with TLS and Let's Encrypt](https://about.gitlab.com/2016/04/11/tutorial-securing-your-gitlab-pages-with-tls-and-letsencrypt/) | Tutorial | 2016-04-11 | -| [Hosting on GitLab.com with GitLab Pages](https://about.gitlab.com/2016/04/07/gitlab-pages-setup/) | Tutorial | 2016-04-07 | - -## Install and maintain GitLab - -[Admin](../README.md#administrator-documentation), [install](../install/README.md), -upgrade, integrate, migrate to GitLab: - -| Article title | Category | Publishing date | -| :------------ | :------: | --------------: | -| [Video Tutorial: Idea to Production on Google Container Engine (GKE)](https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-production-on-google-container-engine-gke/) | Tutorial | 2017-01-23 | -| [How to Setup a GitLab Instance on Microsoft Azure](https://about.gitlab.com/2016/07/13/how-to-setup-a-gitlab-instance-on-microsoft-azure/) | Tutorial | 2016-07-13 | -| [Getting started with GitLab and DigitalOcean](https://about.gitlab.com/2016/04/27/getting-started-with-gitlab-and-digitalocean/) | Tutorial | 2016-04-27 | - -## Software development - -Explore the best of GitLab's software development's capabilities: - -| Article title | Category | Publishing date | -| :------------ | :------: | --------------: | -| [Making CI Easier with GitLab](https://about.gitlab.com/2017/07/13/making-ci-easier-with-gitlab/) | Concepts | 2017-07-13 | -| [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci/)| Concepts | 2017-06-29 | -| [Fast and Natural Continuous Integration with GitLab CI](https://about.gitlab.com/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/) | Concepts | 2017-05-22 | -| [Demo: Auto-Deploy from GitLab to an OpenShift Container Cluster](https://about.gitlab.com/2017/05/16/devops-containers-gitlab-openshift/) | Technical overview | 2017-05-16 | -| [Demo: GitLab Service Desk](https://about.gitlab.com/2017/05/09/demo-service-desk/) | Feature highlight | 2017-05-09 | -| [Demo: Mapping Work Versus Time, With Burndown Charts](https://about.gitlab.com/2017/04/25/mapping-work-to-do-versus-time-with-burndown-charts/) | Feature highlight | 2017-04-25 | -| [Demo: Cloud Native Development with GitLab](https://about.gitlab.com/2017/04/18/cloud-native-demo/) | Feature highlight | 2017-04-18 | -| [Demo: Mastering Code Review With GitLab](https://about.gitlab.com/2017/03/17/demo-mastering-code-review-with-gitlab/) | Feature highlight | 2017-03-17 | -| [In 13 minutes from Kubernetes to a complete application development tool](https://about.gitlab.com/2016/11/14/idea-to-production/) | Technical overview | 2016-11-14 | -| [GitLab Workflow, an Overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/) | Technical overview | 2016-10-25 | -| [Trends in Version Control Land: Microservices](https://about.gitlab.com/2016/08/16/trends-in-version-control-land-microservices/) | Concepts | 2016-08-16 | -| [Continuous Integration, Delivery, and Deployment with GitLab](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) | Concepts | 2016-08-05 | -| [Trends in Version Control Land: Innersourcing](https://about.gitlab.com/2016/07/07/trends-version-control-innersourcing/) | Concepts | 2016-07-07 | -| [Tutorial: It's all connected in GitLab](https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/) | Technical overview | 2016-03-08 | - -## Technologies - -| Article title | Category | Publishing date | -| :------------ | :------: | --------------: | -| [Why we are not leaving the cloud](https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/) | Concepts | 2017-03-02 | -| [Why We Chose Vue.js](https://about.gitlab.com/2016/10/20/why-we-chose-vue/) | Concepts | 2016-10-20 | -| [Markdown Kramdown Tips & Tricks](https://about.gitlab.com/2016/07/19/markdown-kramdown-tips-and-tricks/) | Technical overview | 2016-07-19 | +- [Git](../topics/git/index.md) +- [GitLab administrator](../administration/index.md) +- [GitLab CI/CD](../ci/README.md) +- [GitLab Pages](../user/project/pages/index.md) +- [Install GitLab](../install/README.md) diff --git a/doc/articles/numerous_undo_possibilities_in_git/index.md b/doc/articles/numerous_undo_possibilities_in_git/index.md index 895bbccec08..3f46ee9a5e6 100644 --- a/doc/articles/numerous_undo_possibilities_in_git/index.md +++ b/doc/articles/numerous_undo_possibilities_in_git/index.md @@ -1,497 +1 @@ -# Numerous undo possibilities in Git - -> **Article [Type](../../development/writing_documentation.md#types-of-technical-articles):** tutorial || -> **Level:** intermediary || -> **Author:** [Crt Mori](https://gitlab.com/Letme) || -> **Publication date:** 2017-08-17 - -## Introduction - -In this tutorial, we will show you different ways of undoing your work in Git, for which -we will assume you have a basic working knowledge of. Check GitLab's -[Git documentation](../../topics/git/index.md#git-documentation) for reference. -Also, we will only provide some general info of the commands, which is enough -to get you started for the easy cases/examples, but for anything more advanced please refer to the [Git book](https://git-scm.com/book/en/v2). - -We will explain a few different techniques to undo your changes based on the stage -of the change in your current development. Also, keep in mind that [nothing in -Git is really deleted.][git-autoclean-ref] -This means that until Git automatically cleans detached commits (which cannot be -accessed by branch or tag) it will be possible to view them with `git reflog` command -and access them with direct commit-id. Read more about _[redoing the undo](#redoing-the-undo)_ on the section below. - -This guide is organized depending on the [stage of development][git-basics] -where you want to undo your changes from and if they were shared with other developers -or not. Because Git is tracking changes a created or edited file is in the unstaged state -(if created it is untracked by Git). After you add it to a repository (`git add`) you put -a file into the **staged** state, which is then committed (`git commit`) to your -local repository. After that, file can be shared with other developers (`git push`). -Here's what we'll cover in this tutorial: - - - [Undo local changes](#undo-local-changes) which were not pushed to remote repository - - - Before you commit, in both unstaged and staged state - - After you committed - - - Undo changes after they are pushed to remote repository - - - [Without history modification](#undo-remote-changes-without-changing-history) (preferred way) - - [With history modification](#undo-remote-changes-with-modifying-history) (requires - coordination with team and force pushes). - - - [Usecases when modifying history is generally acceptable](#where-modifying-history-is-generally-acceptable) - - [How to modify history](#how-modifying-history-is-done) - - [How to remove sensitive information from repository](#deleting-sensitive-information-from-commits) - - -### Branching strategy - -[Git][git-official] is a de-centralized version control system, which means that beside regular -versioning of the whole repository, it has possibilities to exchange changes -with other repositories. To avoid chaos with -[multiple sources of truth][git-distributed], various -development workflows have to be followed, and it depends on your internal -workflow how certain changes or commits can be undone or changed. -[GitLab Flow][gitlab-flow] provides a good -balance between developers clashing with each other while -developing the same feature and cooperating seamlessly, but it does not enable -joined development of the same feature by multiple developers by default. -When multiple developers develop the same feature on the same branch, clashing -with every synchronization is unavoidable, but a proper or chosen Git Workflow will -prevent that anything is lost or out of sync when feature is complete. You can also -read through this blog post on [Git Tips & Tricks][gitlab-git-tips-n-tricks] -to learn how to easily **do** things in Git. - - -## Undo local changes - -Until you push your changes to any remote repository, they will only affect you. -That broadens your options on how to handle undoing them. Still, local changes -can be on various stages and each stage has a different approach on how to tackle them. - - -### Unstaged local changes (before you commit) - -When a change is made, but it is not added to the staged tree, Git itself -proposes a solution to discard changes to certain file. - -Suppose you edited a file to change the content using your favorite editor: - -```shell -vim <file> -``` - -Since you did not `git add <file>` to staging, it should be under unstaged files (or -untracked if file was created). You can confirm that with: - -```shell -$ git status -On branch master -Your branch is up-to-date with 'origin/master'. -Changes not staged for commit: - (use "git add <file>..." to update what will be committed) - (use "git checkout -- <file>..." to discard changes in working directory) - - modified: <file> -no changes added to commit (use "git add" and/or "git commit -a") -``` - -At this point there are 3 options to undo the local changes you have: - - - Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes) - - ```shell - git stash - ``` - - - Discarding local changes (permanently) to a file - - ```shell - git checkout -- <file> - ``` - - - Discard all local changes to all files permanently - - ```shell - git reset --hard - ``` - - -Before executing `git reset --hard`, keep in mind that there is also a way to -just temporary store the changes without committing them using `git stash`. -This command resets the changes to all files, but it also saves them in case -you would like to apply them at some later time. You can read more about it in -[section below](#quickly-save-local-changes). - -### Quickly save local changes - -You are working on a feature when a boss drops by with an urgent task. Since your -feature is not complete, but you need to swap to another branch, you can use -`git stash` to save what you had done, swap to another branch, commit, push, -test, then get back to previous feature branch, do `git stash pop` and continue -where you left. - -The example above shows that discarding all changes is not always a preferred option, -but Git provides a way to save them for later, while resetting the repository to state without -them. This is achieved by Git stashing command `git stash`, which in fact saves your -current work and runs `git reset --hard`, but it also has various -additional options like: - - - `git stash save`, which enables including temporary commit message, which will help you identify changes, among with other options - - `git stash list`, which lists all previously stashed commits (yes, there can be more) that were not `pop`ed - - `git stash pop`, which redoes previously stashed changes and removes them from stashed list - - `git stash apply`, which redoes previously stashed changes, but keeps them on stashed list - -### Staged local changes (before you commit) - -Let's say you have added some files to staging, but you want to remove them from the -current commit, yet you want to retain those changes - just move them outside -of the staging tree. You also have an option to discard all changes with -`git reset --hard` or think about `git stash` [as described earlier.](#quickly-save-local-changes) - -Lets start the example by editing a file, with your favorite editor, to change the -content and add it to staging - -``` -vim <file> -git add <file> -``` - -The file is now added to staging as confirmed by `git status` command: - -```shell -$ git status -On branch master -Your branch is up-to-date with 'origin/master'. -Changes to be committed: - (use "git reset HEAD <file>..." to unstage) - - new file: <file> -``` - -Now you have 4 options to undo your changes: - - - Unstage the file to current commit (HEAD) - - ```shell - git reset HEAD <file> - ``` - - - Unstage everything - retain changes - - ```shell - git reset - ``` - - - Discard all local changes, but save them for [later](#quickly-save-local-changes) - - ```shell - git stash - ``` - - - Discard everything permanently - - ```shell - git reset --hard - ``` - -## Committed local changes - -Once you commit, your changes are recorded by the version control system. -Because you haven't pushed to your remote repository yet, your changes are -still not public (or shared with other developers). At this point, undoing -things is a lot easier, we have quite some workaround options. Once you push -your code, you'll have less options to troubleshoot your work. - -### Without modifying history - -Through the development process some of the previously committed changes do not -fit anymore in the end solution, or are source of the bugs. Once you find the -commit which triggered bug, or once you have a faulty commit, you can simply -revert it with `git revert commit-id`. This command inverts (swaps) the additions and -deletions in that commit, so that it does not modify history. Retaining history -can be helpful in future to notice that some changes have been tried -unsuccessfully in the past. - -In our example we will assume there are commits `A`,`B`,`C`,`D`,`E` committed in this order: `A-B-C-D-E`, -and `B` is the commit you want to undo. There are many different ways to identify commit -`B` as bad, one of them is to pass a range to `git bisect` command. The provided range includes -last known good commit (we assume `A`) and first known bad commit (where bug was detected - we will assume `E`). - -```shell -git bisect A..E -``` - -Bisect will provide us with commit-id of the middle commit to test, and then guide us -through simple bisection process. You can read more about it [in official Git Tools][git-debug] -In our example we will end up with commit `B`, that introduced bug/error. We have -4 options on how to remove it (or part of it) from our repository. - -- Undo (swap additions and deletions) changes introduced by commit `B`. - - ```shell - git revert commit-B-id - ``` - -- Undo changes on a single file or directory from commit `B`, but retain them in the staged state - - ```shell - git checkout commit-B-id <file> - ``` - -- Undo changes on a single file or directory from commit `B`, but retain them in the unstaged state - - ```shell - git reset commit-B-id <file> - ``` - - - There is one command we also must not forget: **creating a new branch** - from the point where changes are not applicable or where the development has hit a - dead end. For example you have done commits `A-B-C-D` on your feature-branch - and then you figure `C` and `D` are wrong. At this point you either reset to `B` - and do commit `F` (which will cause problems with pushing and if forced pushed also with other developers) - since branch now looks `A-B-F`, which clashes with what other developers have locally (you will - [change history](#with-history-modification)), or you simply checkout commit `B` create - a new branch and do commit `F`. In the last case, everyone else can still do their work while you - have your new way to get it right and merge it back in later. Alternatively, with GitLab, - you can [cherry-pick](../../user/project/merge_requests/cherry_pick_changes.md#cherry-picking-a-commit) - that commit into a new merge request. - -  - - ```shell - git checkout commit-B-id - git checkout -b new-path-of-feature - # Create <commit F> - git commit -a - ``` - -### With history modification - -There is one command for history modification and that is `git rebase`. Command -provides interactive mode (`-i` flag) which enables you to: - - - **reword** commit messages (there is also `git commit --amend` for editing - last commit message) - - **edit** the commit content (changes introduced by commit) and message - - **squash** multiple commits into a single one, and have a custom or aggregated - commit message - - **drop** commits - simply delete them - - and few more options - -Let us check few examples. Again there are commits `A-B-C-D` where you want to -delete commit `B`. - -- Rebase the range from current commit D to A: - - ```shell - git rebase -i A - ``` - -- Command opens your favorite editor where you write `drop` in front of commit - `B`, but you leave default `pick` with all other commits. Save and exit the - editor to perform a rebase. Remember: if you want to cancel delete whole - file content before saving and exiting the editor - -In case you want to modify something introduced in commit `B`. - -- Rebase the range from current commit D to A: - - ```shell - git rebase -i A - ``` - -- Command opens your favorite text editor where you write `edit` in front of commit - `B`, but leave default `pick` with all other commits. Save and exit the editor to - perform a rebase - -- Now do your edits and commit changes: - - ```shell - git commit -a - ``` - -You can find some more examples in [below section where we explain how to modify -history](#how-modifying-history-is-done) - - -### Redoing the Undo - -Sometimes you realize that the changes you undid were useful and you want them -back. Well because of first paragraph you are in luck. Command `git reflog` -enables you to *recall* detached local commits by referencing or applying them -via commit-id. Although, do not expect to see really old commits in reflog, because -Git regularly [cleans the commits which are *unreachable* by branches or tags][git-autoclean-ref]. - -To view repository history and to track older commits you can use below command: - -```shell -$ git reflog show - -# Example output: -b673187 HEAD@{4}: merge 6e43d5987921bde189640cc1e37661f7f75c9c0b: Merge made by the 'recursive' strategy. -eb37e74 HEAD@{5}: rebase -i (finish): returning to refs/heads/master -eb37e74 HEAD@{6}: rebase -i (pick): Commit C -97436c6 HEAD@{7}: rebase -i (start): checkout 97436c6eec6396c63856c19b6a96372705b08b1b -... -88f1867 HEAD@{12}: commit: Commit D -97436c6 HEAD@{13}: checkout: moving from 97436c6eec6396c63856c19b6a96372705b08b1b to test -97436c6 HEAD@{14}: checkout: moving from master to 97436c6 -05cc326 HEAD@{15}: commit: Commit C -6e43d59 HEAD@{16}: commit: Commit B -``` - -Output of command shows repository history. In first column there is commit-id, -in following column, number next to `HEAD` indicates how many commits ago something -was made, after that indicator of action that was made (commit, rebase, merge, ...) -and then on end description of that action. - -## Undo remote changes without changing history - -This topic is roughly same as modifying committed local changes without modifying -history. **It should be the preferred way of undoing changes on any remote repository -or public branch.** Keep in mind that branching is the best solution when you want -to retain the history of faulty development, yet start anew from certain point. Branching -enables you to include the existing changes in new development (by merging) and -it also provides a clear timeline and development structure. - - - -If you want to revert changes introduced in certain `commit-id` you can simply -revert that `commit-id` (swap additions and deletions) in newly created commit: -You can do this with - -```shell -git revert commit-id -``` - -or creating a new branch: - -```shell -git checkout commit-id -git checkout -b new-path-of-feature -``` - -## Undo remote changes with modifying history - -This is useful when you want to *hide* certain things - like secret keys, -passwords, SSH keys, etc. It is and should not be used to hide mistakes, as -it will make it harder to debug in case there are some other bugs. The main -reason for this is that you loose the real development progress. **Also keep in -mind that, even with modified history, commits are just detached and can still be -accessed through commit-id** - at least until all repositories perform -the cleanup of detached commits (happens automatically). - - - -### Where modifying history is generally acceptable - -Modified history breaks the development chain of other developers, as changed -history does not have matching commits'ids. For that reason it should not -be used on any public branch or on branch that *might* be used by other -developers. When contributing to big open source repositories (e.g. [GitLab CE][gitlab-ce]), -it is acceptable to *squash* commits into a single one, to present -a nicer history of your contribution. -Keep in mind that this also removes the comments attached to certain commits -in merge requests, so if you need to retain traceability in GitLab, then -modifying history is not acceptable. -A feature-branch of a merge request is a public branch and might be used by -other developers, but project process and rules might allow or require -you to use `git rebase` (command that changes history) to reduce number of -displayed commits on target branch after reviews are done (for example -GitLab). There is a `git merge --squash` command which does exactly that -(squashes commits on feature-branch to a single commit on target branch -at merge). - ->**Note:** -Never modify the commit history of `master` or shared branch - -### How modifying history is done - -After you know what you want to modify (how far in history or how which range of -old commits), use `git rebase -i commit-id`. This command will then display all the commits from -current version to chosen commit-id and allow modification, squashing, deletion -of that commits. - -```shell -$ git rebase -i commit1-id..commit3-id -pick <commit1-id> <commit1-commit-message> -pick <commit2-id> <commit2-commit-message> -pick <commit3-id> <commit3-commit-message> - -# Rebase commit1-id..commit3-id onto <commit4-id> (3 command(s)) -# -# Commands: -# p, pick = use commit -# r, reword = use commit, but edit the commit message -# e, edit = use commit, but stop for amending -# s, squash = use commit, but meld into previous commit -# f, fixup = like "squash", but discard this commit's log message -# x, exec = run command (the rest of the line) using shell -# d, drop = remove commit -# -# These lines can be re-ordered; they are executed from top to bottom. -# -# If you remove a line here THAT COMMIT WILL BE LOST. -# -# However, if you remove everything, the rebase will be aborted. -# -# Note that empty commits are commented out -``` - ->**Note:** -It is important to notice that comment from the output clearly states that, if -you decide to abort, then do not just close your editor (as that will in-fact -modify history), but remove all uncommented lines and save. - -That is one of the reasons why `git rebase` should be used carefully on -shared and remote branches. But don't worry, there will be nothing broken until -you push back to the remote repository (so you can freely explore the -different outcomes locally). - -```shell -# Modify history from commit-id to HEAD (current commit) -git rebase -i commit-id -``` - -### Deleting sensitive information from commits - -Git also enables you to delete sensitive information from your past commits and -it does modify history in the progress. That is why we have included it in this -section and not as a standalone topic. To do so, you should run the -`git filter-branch`, which enables you to rewrite history with -[certain filters][git-filters-manual]. -This command uses rebase to modify history and if you want to remove certain -file from history altogether use: - -```shell -git filter-branch --tree-filter 'rm filename' HEAD -``` - -Since `git filter-branch` command might be slow on big repositories, there are -tools that can use some of Git specifics to enable faster execution of common -tasks (which is exactly what removing sensitive information file is about). -An alternative is [BFG Repo-cleaner][bfg-repo-cleaner]. Keep in mind that these -tools are faster because they do not provide a same fully feature set as `git filter-branch` -does, but focus on specific usecases. - -## Conclusion - -There are various options of undoing your work with any version control system, but -because of de-centralized nature of Git, these options are multiplied (or limited) -depending on the stage of your process. Git also enables rewriting history, but that -should be avoided as it might cause problems when multiple developers are -contributing to the same codebase. - -<!-- Identifiers, in alphabetical order --> - -[bfg-repo-cleaner]: https://rtyley.github.io/bfg-repo-cleaner/ -[git-autoclean-ref]: https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery -[git-basics]: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository -[git-debug]: https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git -[git-distributed]: https://git-scm.com/about/distributed -[git-filters-manual]: https://git-scm.com/docs/git-filter-branch#_options -[git-official]: https://git-scm.com/ -[gitlab-ce]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#contribution-acceptance-criteria -[gitlab-flow]: https://about.gitlab.com/2014/09/29/gitlab-flow/ -[gitlab-git-tips-n-tricks]: https://about.gitlab.com/2016/12/08/git-tips-and-tricks/ +This document was moved to [another location](../../topics/git/numerous_undo_possibilities_in_git/index.md). diff --git a/doc/articles/runner_autoscale_aws/index.md b/doc/articles/runner_autoscale_aws/index.md index 9d4c4a57ce5..e2667aebc5f 100644 --- a/doc/articles/runner_autoscale_aws/index.md +++ b/doc/articles/runner_autoscale_aws/index.md @@ -1,410 +1 @@ ---- -last_updated: 2017-11-24 ---- - -> **[Article Type](../../development/writing_documentation.html#types-of-technical-articles):** Admin guide || -> **Level:** intermediary || -> **Author:** [Achilleas Pipinellis](https://gitlab.com/axil) || -> **Publication date:** 2017/11/24 - -# Autoscaling GitLab Runner on AWS - -One of the biggest advantages of GitLab Runner is its ability to automatically -spin up and down VMs to make sure your builds get processed immediately. It's a -great feature, and if used correctly, it can be extremely useful in situations -where you don't use your Runners 24/7 and want to have a cost-effective and -scalable solution. - -## Introduction - -In this tutorial, we'll explore how to properly configure a GitLab Runner in -AWS that will serve as the bastion where it will spawn new Docker machines on -demand. - -In addition, we'll make use of [Amazon's EC2 Spot instances][spot] which will -greatly reduce the costs of the Runner instances while still using quite -powerful autoscaling machines. - -## Prerequisites - -NOTE: **Note:** -A familiarity with Amazon Web Services (AWS) is required as this is where most -of the configuration will take place. - -Your GitLab instance is going to need to talk to the Runners over the network, -and that is something you need think about when configuring any AWS security -groups or when setting up your DNS configuration. - -For example, you can keep the EC2 resources segmented away from public traffic -in a different VPC to better strengthen your network security. Your environment -is likely different, so consider what works best for your situation. - -### AWS security groups - -Docker Machine will attempt to use a -[default security group](https://docs.docker.com/machine/drivers/aws/#security-group) -with rules for port `2376`, which is required for communication with the Docker -daemon. Instead of relying on Docker, you can create a security group with the -rules you need and provide that in the Runner options as we will -[see below](#the-runners-machine-section). This way, you can customize it to your -liking ahead of time based on your networking environment. - -### AWS credentials - -You'll need an [AWS Access Key](https://docs.aws.amazon.com/general/latest/gr/managing-aws-access-keys.html) -tied to a user with permission to scale (EC2) and update the cache (via S3). -Create a new user with [policies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html) -for EC2 (AmazonEC2FullAccess) and S3 (AmazonS3FullAccess). To be more secure, -you can disable console login for that user. Keep the tab open or copy paste the -security credentials in an editor as we'll use them later during the -[Runner configuration](#the-runners-machine-section). - -## Prepare the bastion instance - -The first step is to install GitLab Runner in an EC2 instance that will serve -as the bastion that spawns new machines. This doesn't have to be a powerful -machine since it will not run any jobs itself, a `t2.micro` instance will do. -This machine will be a dedicated host since we need it always up and running, -thus it will be the only standard cost. - -NOTE: **Note:** -For the bastion instance, choose a distribution that both Docker and GitLab -Runner support, for example either Ubuntu, Debian, CentOS or RHEL will work fine. - -Install the prerequisites: - -1. Log in to your server -1. [Install GitLab Runner from the official GitLab repository](https://docs.gitlab.com/runner/install/linux-repository.html) -1. [Install Docker](https://docs.docker.com/engine/installation/#server) -1. [Install Docker Machine](https://docs.docker.com/machine/install-machine/) - -Now that the Runner is installed, it's time to register it. - -## Registering the GitLab Runner - -Before configuring the GitLab Runner, you need to first register it, so that -it connects with your GitLab instance: - -1. [Obtain a Runner token](../../ci/runners/README.md) -1. [Register the Runner](https://docs.gitlab.com/runner/register/index.html#gnu-linux) -1. When asked the executor type, enter `docker+machine` - -You can now move on to the most important part, configuring the GitLab Runner. - -TIP: **Tip:** -If you want every user in your instance to be able to use the autoscaled Runners, -register the Runner as a shared one. - -## Configuring the GitLab Runner - -Now that the Runner is registered, you need to edit its configuration file and -add the required options for the AWS machine driver. - -Let's first break it down to pieces. - -### The global section - -In the global section, you can define the limit of the jobs that can be run -concurrently across all Runners (`concurrent`). This heavily depends on your -needs, like how many users your Runners will accommodate, how much time your -builds take, etc. You can start with something low like `10`, and increase or -decrease its value going forward. - -The `check_interval` option defines how often the Runner should check GitLab -for new jobs, in seconds. - -Example: - -```toml -concurrent = 10 -check_interval = 0 -``` - -[Read more](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section) -about all the options you can use. - -### The `runners` section - -From the `[[runners]]` section, the most important part is the `executor` which -must be set to `docker+machine`. Most of those settings are taken care of when -you register the Runner for the first time. - -`limit` sets the maximum number of machines (running and idle) that this Runner -will spawn. For more info check the [relationship between `limit`, `concurrent` -and `IdleCount`](https://docs.gitlab.com/runner/configuration/autoscale.html#how-concurrent-limit-and-idlecount-generate-the-upper-limit-of-running-machines). - -Example: - -```toml -[[runners]] - name = "gitlab-aws-autoscaler" - url = "<URL of your GitLab instance>" - token = "<Runner's token>" - executor = "docker+machine" - limit = 20 -``` - -[Read more](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) -about all the options you can use under `[[runners]]`. - -### The `runners.docker` section - -In the `[runners.docker]` section you can define the default Docker image to -be used by the child Runners if it's not defined in [`.gitlab-ci.yml`](../../ci/yaml/README.md). -By using `privileged = true`, all Runners will be able to run -[Docker in Docker](../../ci/docker/using_docker_build.md#use-docker-in-docker-executor) -which is useful if you plan to build your own Docker images via GitLab CI/CD. - -Next, we use `disable_cache = true` to disable the Docker executor's inner -cache mechanism since we will use the distributed cache mode as described -in the following section. - -Example: - -```toml - [runners.docker] - image = "alpine" - privileged = true - disable_cache = true -``` - -[Read more](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-docker-section) -about all the options you can use under `[runners.docker]`. - -### The `runners.cache` section - -To speed up your jobs, GitLab Runner provides a cache mechanism where selected -directories and/or files are saved and shared between subsequent jobs. -While not required for this setup, it is recommended to use the distributed cache -mechanism that GitLab Runner provides. Since new instances will be created on -demand, it is essential to have a common place where the cache is stored. - -In the following example, we use Amazon S3: - -```toml - [runners.cache] - Type = "s3" - ServerAddress = "s3.amazonaws.com" - AccessKey = "<your AWS Access Key ID>" - SecretKey = "<your AWS Secret Access Key>" - BucketName = "<the bucket where your cache should be kept>" - BucketLocation = "us-east-1" - Shared = true -``` - -Here's some more info to further explore the cache mechanism: - -- [Reference for `runners.cache`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-cache-section) -- [Deploying and using a cache server for GitLab Runner](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) -- [How cache works](../../ci/yaml/README.md#cache) - -### The `runners.machine` section - -This is the most important part of the configuration and it's the one that -tells GitLab Runner how and when to spawn new or remove old Docker Machine -instances. - -We will focus on the AWS machine options, for the rest of the settings read -about the: - -- [Autoscaling algorithm and the parameters it's based on](https://docs.gitlab.com/runner/configuration/autoscale.html#autoscaling-algorithm-and-parameters) - depends on the needs of your organization -- [Off peak time configuration](https://docs.gitlab.com/runner/configuration/autoscale.html#off-peak-time-mode-configuration) - useful when there are regular time periods in your organization when no work is done, for example weekends - -Here's an example of the `runners.machine` section: - -```toml - [runners.machine] - IdleCount = 1 - IdleTime = 1800 - MaxBuilds = 10 - OffPeakPeriods = [ - "* * 0-9,18-23 * * mon-fri *", - "* * * * * sat,sun *" - ] - OffPeakIdleCount = 0 - OffPeakIdleTime = 1200 - MachineDriver = "amazonec2" - MachineName = "gitlab-docker-machine-%s" - MachineOptions = [ - "amazonec2-access-key=XXXX", - "amazonec2-secret-key=XXXX", - "amazonec2-region=us-central-1", - "amazonec2-vpc-id=vpc-xxxxx", - "amazonec2-subnet-id=subnet-xxxxx", - "amazonec2-use-private-address=true", - "amazonec2-tags=runner-manager-name,gitlab-aws-autoscaler,gitlab,true,gitlab-runner-autoscale,true", - "amazonec2-security-group=docker-machine-scaler", - "amazonec2-instance-type=m4.2xlarge", - ] -``` - -The Docker Machine driver is set to `amazonec2` and the machine name has a -standard prefix followed by `%s` (required) that is replaced by the ID of the -child Runner: `gitlab-docker-machine-%s`. - -Now, depending on your AWS infrastructure, there are many options you can set up -under `MachineOptions`. Below you can see the most common ones. - -| Machine option | Description | -| -------------- | ----------- | -| `amazonec2-access-key=XXXX` | The AWS access key of the user that has permissions to create EC2 instances, see [AWS credentials](#aws-credentials). | -| `amazonec2-secret-key=XXXX` | The AWS secret key of the user that has permissions to create EC2 instances, see [AWS credentials](#aws-credentials). | -| `amazonec2-region=eu-central-1` | The region to use when launching the instance. You can omit this entirely and the default `us-east-1` will be used. | -| `amazonec2-vpc-id=vpc-xxxxx` | Your [VPC ID](https://docs.docker.com/machine/drivers/aws/#vpc-id) to launch the instance in. | -| `amazonec2-subnet-id=subnet-xxxx` | The AWS VPC subnet ID. | -| `amazonec2-use-private-address=true` | Use the private IP address of Docker Machines, but still create a public IP address. Useful to keep the traffic internal and avoid extra costs.| -| `amazonec2-tags=runner-manager-name,gitlab-aws-autoscaler,gitlab,true,gitlab-runner-autoscale,true` | AWS extra tag key-value pairs, useful to identify the instances on the AWS console. The "Name" tag is set to the machine name by default. We set the "runner-manager-name" to match the Runner name set in `[[runners]]`, so that we can filter all the EC2 instances created by a specific manager setup. Read more about [using tags in AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html). | -| `amazonec2-security-group=docker-machine-scaler` | AWS VPC security group name, see [AWS security groups](#aws-security-groups). | -| `amazonec2-instance-type=m4.2xlarge` | The instance type that the child Runners will run on. | - -TIP: **Tip:** -Under `MachineOptions` you can add anything that the [AWS Docker Machine driver -supports](https://docs.docker.com/machine/drivers/aws/#options). You are highly -encouraged to read Docker's docs as your infrastructure setup may warrant -different options to be applied. - -NOTE: **Note:** -The child instances will use by default Ubuntu 16.04 unless you choose a -different AMI ID by setting `amazonec2-ami`. - -NOTE: **Note:** -If you specify `amazonec2-private-address-only=true` as one of the machine -options, your EC2 instance won't get assigned a public IP. This is ok if your -VPC is configured correctly with an Internet Gateway (IGW) and routing is fine, -but it’s something to consider if you've got a more complex configuration. Read -more in [Docker docs about VPC connectivity](https://docs.docker.com/machine/drivers/aws/#vpc-connectivity). - -[Read more](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-machine-section) -about all the options you can use under `[runners.machine]`. - -### Getting it all together - -Here's the full example of `/etc/gitlab-runner/config.toml`: - -```toml -concurrent = 10 -check_interval = 0 - -[[runners]] - name = "gitlab-aws-autoscaler" - url = "<URL of your GitLab instance>" - token = "<Runner's token>" - executor = "docker+machine" - limit = 20 - [runners.docker] - image = "alpine" - privileged = true - disable_cache = true - [runners.cache] - Type = "s3" - ServerAddress = "s3.amazonaws.com" - AccessKey = "<your AWS Access Key ID>" - SecretKey = "<your AWS Secret Access Key>" - BucketName = "<the bucket where your cache should be kept>" - BucketLocation = "us-east-1" - Shared = true - [runners.machine] - IdleCount = 1 - IdleTime = 1800 - MaxBuilds = 100 - OffPeakPeriods = [ - "* * 0-9,18-23 * * mon-fri *", - "* * * * * sat,sun *" - ] - OffPeakIdleCount = 0 - OffPeakIdleTime = 1200 - MachineDriver = "amazonec2" - MachineName = "gitlab-docker-machine-%s" - MachineOptions = [ - "amazonec2-access-key=XXXX", - "amazonec2-secret-key=XXXX", - "amazonec2-region=us-central-1", - "amazonec2-vpc-id=vpc-xxxxx", - "amazonec2-subnet-id=subnet-xxxxx", - "amazonec2-use-private-address=true", - "amazonec2-tags=runner-manager-name,gitlab-aws-autoscaler,gitlab,true,gitlab-runner-autoscale,true", - "amazonec2-security-group=docker-machine-scaler", - "amazonec2-instance-type=m4.2xlarge", - ] -``` - -## Cutting down costs with Amazon EC2 Spot instances - -As [described by][spot] Amazon: - -> -Amazon EC2 Spot instances allow you to bid on spare Amazon EC2 computing capacity. -Since Spot instances are often available at a discount compared to On-Demand -pricing, you can significantly reduce the cost of running your applications, -grow your application’s compute capacity and throughput for the same budget, -and enable new types of cloud computing applications. - -In addition to the [`runners.machine`](#the-runners-machine-section) options -you picked above, in `/etc/gitlab-runner/config.toml` under the `MachineOptions` -section, add the following: - -```toml - MachineOptions = [ - "amazonec2-request-spot-instance=true", - "amazonec2-spot-price=0.03", - "amazonec2-block-duration-minutes=60" - ] -``` - -With this configuration, Docker Machines are created on Spot instances with a -maximum bid price of $0.03 per hour and the duration of the Spot instance is -capped at 60 minutes. The `0.03` number mentioned above is just an example, so -be sure to check on the current pricing based on the region you picked. - -To learn more about Amazon EC2 Spot instances, visit the following links: - -- https://aws.amazon.com/ec2/spot/ -- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html -- https://aws.amazon.com/blogs/aws/focusing-on-spot-instances-lets-talk-about-best-practices/ - -### Caveats of Spot instances - -While Spot instances is a great way to use unused resources and minimize the -costs of your infrastructure, you must be aware of the implications. - -Running CI jobs on Spot instances may increase the failure rates because of the -Spot instances pricing model. If the price exceeds your bid, the existing Spot -instances will be immediately terminated and all your jobs on that host will fail. - -As a consequence, the auto-scale Runner would fail to create new machines while -it will continue to request new instances. This eventually will make 60 requests -and then AWS won't accept any more. Then once the Spot price is acceptable, you -are locked out for a bit because the call amount limit is exceeded. - -If you encounter that case, you can use the following command in the bastion -machine to see the Docker Machines state: - -```sh -docker-machine ls -q --filter state=Error --format "{{.NAME}}" -``` - -NOTE: **Note:** -There are some issues regarding making GitLab Runner gracefully handle Spot -price changes, and there are reports of `docker-machine` attempting to -continually remove a Docker Machine. GitLab has provided patches for both cases -in the upstream project. For more information, see issues -[#2771](https://gitlab.com/gitlab-org/gitlab-runner/issues/2771) and -[#2772](https://gitlab.com/gitlab-org/gitlab-runner/issues/2772). - -## Conclusion - -In this guide we learned how to install and configure a GitLab Runner in -autoscale mode on AWS. - -Using the autoscale feature of GitLab Runner can save you both time and money. -Using the Spot instances that AWS provides can save you even more, but you must -be aware of the implications. As long as your bid is high enough, there shouldn't -be an issue. - -You can read the following use cases from which this tutorial was (heavily) -influenced: - -- [HumanGeo - Scaling GitLab CI](http://blog.thehumangeo.com/gitlab-autoscale-runners.html) -- [subtrakt Health - Autoscale GitLab CI Runners and save 90% on EC2 costs](https://substrakthealth.com/news/gitlab-ci-cost-savings/) - -[spot]: https://aws.amazon.com/ec2/spot/ +This document was moved to [another location](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/index.html). diff --git a/doc/ci/README.md b/doc/ci/README.md index 5829aaee9c9..eabeb4510db 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -2,151 +2,120 @@ comments: false --- -# GitLab Continuous Integration (GitLab CI) +# GitLab Continuous Integration (GitLab CI/CD)  The benefits of Continuous Integration are huge when automation plays an integral part of your workflow. GitLab comes with built-in Continuous -Integration, Continuous Deployment, and Continuous Delivery support to build, -test, and deploy your application. +Integration, Continuous Deployment, and Continuous Delivery support +to build, test, and deploy your application. Here's some info we've gathered to get you started. ## Getting started -The first steps towards your GitLab CI journey. +The first steps towards your GitLab CI/CD journey. -- [Getting started with GitLab CI](quick_start/README.md) -- [Pipelines and jobs](pipelines.md) -- [Configure a Runner, the application that runs your jobs](runners/README.md) -- **Articles:** - - [Getting started with GitLab and GitLab CI - Intro to CI](https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) - - [Continuous Integration, Delivery, and Deployment with GitLab - Intro to CI/CD](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) - - [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/) - - [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) - - [GitLab CI: Deployment & environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/) +- [Getting started with GitLab CI/CD](quick_start/README.md): understand how GitLab CI/CD works. +- GitLab CI/CD configuration file: [`.gitlab-ci.yml`](yaml/README.md) - Learn all about the ins and outs of `.gitlab-ci.yml`. +- [Pipelines and jobs](pipelines.md): configure your GitLab CI/CD pipelines to build, test, and deploy your application. +- Runners: The [GitLab Runner](https://docs.gitlab.com/runner/) is responsible by running the jobs in your CI/CD pipeline. On GitLab.com, Shared Runners are enabled by default, so +you don't need to set up anything to start to use them with GitLab CI/CD. + +### Introduction to GitLab CI/CD + +- Article (2016-08-05): [Continuous Integration, Delivery, and Deployment with GitLab - Intro to CI/CD](https://about.gitlab.com/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/) +- Article (2015-12-14): [Getting started with GitLab and GitLab CI - Intro to CI](https://about.gitlab.com/2015/12/14/getting-started-with-gitlab-and-gitlab-ci/) +- Article (2017-07-13): [Making CI Easier with GitLab](https://about.gitlab.com/2017/07/13/making-ci-easier-with-gitlab/) +- Article (2017-05-22): [Fast and Natural Continuous Integration with GitLab CI](https://about.gitlab.com/2017/05/22/fast-and-natural-continuous-integration-with-gitlab-ci/) - **Videos:** - - [Demo (Streamed live on Jul 17, 2017): GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195) - - [Demo (March, 2017): how to get started using CI/CD with GitLab](https://about.gitlab.com/2017/03/13/ci-cd-demo/) - - [Webcast (April, 2016): getting started with CI in GitLab](https://about.gitlab.com/2016/04/20/webcast-recording-and-slides-introduction-to-ci-in-gitlab/) + - Demo (Streamed live on Jul 17, 2017): [GitLab CI/CD Deep Dive](https://youtu.be/pBe4t1CD8Fc?t=195) + - Demo (March, 2017): [How to get started using CI/CD with GitLab](https://about.gitlab.com/2017/03/13/ci-cd-demo/) + - Webcast (April, 2016): [Getting started with CI in GitLab](https://about.gitlab.com/2016/04/20/webcast-recording-and-slides-introduction-to-ci-in-gitlab/) - **Third-party videos:** - [Intégration continue avec GitLab (September, 2016)](https://www.youtube.com/watch?v=URcMBXjIr24&t=13s) - [GitLab CI for Minecraft Plugins (July, 2016)](https://www.youtube.com/watch?v=Z4pcI9F8yf8) -## Reference guides +### Why GitLab CI/CD? -Once you get familiar with the getting started guides, you'll find yourself -digging into specific reference guides. + - Article (2016-10-17): [Why We Chose GitLab CI for our CI/CD Solution](https://about.gitlab.com/2016/10/17/gitlab-ci-oohlala/) + - Article (2016-07-22): [Building our web-app on GitLab CI: 5 reasons why Captain Train migrated from Jenkins to GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/) -- [`.gitlab-ci.yml` reference](yaml/README.md) - Learn all about the ins and - outs of `.gitlab-ci.yml` definitions -- [CI Variables](variables/README.md) - Learn how to use variables defined in +## Exploring GitLab CI/CD + +- [CI/CD Variables](variables/README.md) - Learn how to use variables defined in your `.gitlab-ci.yml` or secured ones defined in your project's settings - **The permissions model** - Learn about the access levels a user can have for performing certain CI actions - [User permissions](../user/permissions.md#gitlab-ci) - [Job permissions](../user/permissions.md#job-permissions) - -## Auto DevOps - -- [Auto DevOps](../topics/autodevops/index.md) - -## GitLab CI + Docker - -Leverage the power of Docker to run your CI pipelines. - -- [Use Docker images with GitLab Runner](docker/using_docker_images.md) -- [Use CI to build Docker images](docker/using_docker_build.md) -- [CI services (linked Docker containers)](services/README.md) -- **Articles:** - - [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) +- [Configure a Runner, the application that runs your jobs](runners/README.md) +- Article (2016-03-01): [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) +- Article (2016-07-29): [GitLab CI: Run jobs sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/) +- Article (2016-08-26): [GitLab CI: Deployment & environments](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/) +- Article (2016-05-23): [Introduction to GitLab Container Registry](https://about.gitlab.com/2016/05/23/gitlab-container-registry/) ## Advanced use -Once you get familiar with the basics of GitLab CI, it's time to dive in and +Once you get familiar with the basics of GitLab CI/CD, it's time to dive in and learn how to leverage its potential even more. -- [Environments and deployments](environments.md) - Separate your jobs into +- [Environments and deployments](environments.md): Separate your jobs into environments and use them for different purposes like testing, building and deploying - [Job artifacts](../user/project/pipelines/job_artifacts.md) -- [Git submodules](git_submodules.md) - How to run your CI jobs when Git +- [Git submodules](git_submodules.md): How to run your CI jobs when Git submodules are involved -- [Auto deploy](autodeploy/index.md) - [Use SSH keys in your build environment](ssh_keys/README.md) - [Trigger pipelines through the GitLab API](triggers/README.md) - [Trigger pipelines on a schedule](../user/project/pipelines/schedules.md) -## Review Apps +## GitLab CI/CD for Docker -- [Review Apps](review_apps/index.md) -- **Articles:** - - [Introducing Review Apps](https://about.gitlab.com/2016/11/22/introducing-review-apps/) - - [Example project that shows how to use Review Apps](https://gitlab.com/gitlab-examples/review-apps-nginx/) +Leverage the power of Docker to run your CI pipelines. -## GitLab CI for GitLab Pages +- [Use Docker images with GitLab Runner](docker/using_docker_images.md) +- [Use CI to build Docker images](docker/using_docker_build.md) +- [CI services (linked Docker containers)](services/README.md) +- Article (2016-03-01): [Setting up GitLab Runner For Continuous Integration](https://about.gitlab.com/2016/03/01/gitlab-runner-with-docker/) -See the topic on [GitLab Pages](../user/project/pages/index.md). +## Review Apps -## Special configuration +- [Review Apps documentation](review_apps/index.md) +- Article (2016-11-22): [Introducing Review Apps](https://about.gitlab.com/2016/11/22/introducing-review-apps/) +- [Example project that shows how to use Review Apps](https://gitlab.com/gitlab-examples/review-apps-nginx/) -You can change the default behavior of GitLab CI in your whole GitLab instance -as well as in each project. +## Auto DevOps -- **Project specific** - - [Pipelines settings](../user/project/pipelines/settings.md) - - [Learn how to enable or disable GitLab CI](enable_or_disable_ci.md) -- **Affecting the whole GitLab instance** - - [Continuous Integration admin settings](../user/admin_area/settings/continuous_integration.md) +- [Auto DevOps](../topics/autodevops/index.md): Auto DevOps automatically detects, builds, tests, deploys, and monitors your applications. + +## GitLab CI for GitLab Pages + +See the documentation on [GitLab Pages](../user/project/pages/index.md). ## Examples ->**Note:** -A collection of `.gitlab-ci.yml` files is maintained at the -[GitLab CI Yml project][gitlab-ci-templates]. -If your favorite programming language or framework is missing we would love -your help by sending a merge request with a `.gitlab-ci.yml`. - -Here is an collection of tutorials and guides on setting up your CI pipeline. - -- [GitLab CI examples](examples/README.md) for the following languages and frameworks: - - [PHP](examples/php.md) - - [Ruby](examples/test-and-deploy-ruby-application-to-heroku.md) - - [Python](examples/test-and-deploy-python-application-to-heroku.md) - - [Clojure](examples/test-clojure-application.md) - - [Scala](examples/test-scala-application.md) - - [Phoenix](examples/test-phoenix-application.md) - - [Run PHP Composer & NPM scripts then deploy them to a staging server](examples/deployment/composer-npm-deploy.md) - - [Analyze code quality with the Code Climate CLI](examples/code_climate.md) -- **Articles** - - [How to test and deploy Laravel/PHP applications with GitLab CI/CD and Envoy](examples/laravel_with_gitlab_and_envoy/index.md) - - [How to deploy Maven projects to Artifactory with GitLab CI/CD](examples/artifactory_and_gitlab/index.md) - - [Automated Debian packaging](https://about.gitlab.com/2016/10/12/automated-debian-package-build-with-gitlab-ci/) - - [Spring boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/) - - [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/) - - [Setting up GitLab CI for Android projects](https://about.gitlab.com/2016/11/30/setting-up-gitlab-ci-for-android-projects/) - - [Building a new GitLab Docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) - - [CI/CD with GitLab in action](https://about.gitlab.com/2017/03/13/ci-cd-demo/) - - [Building an Elixir Release into a Docker image using GitLab CI](https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/) -- **Miscellaneous** - - [Using `dpl` as deployment tool](examples/deployment/README.md) - - [Repositories with examples for various languages](https://gitlab.com/groups/gitlab-examples) - - [The .gitlab-ci.yml file for GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml) - - [Example project that shows how to use Review Apps](https://gitlab.com/gitlab-examples/review-apps-nginx/) +Check the [GitLab CI/CD examples](examples/README.md) for a collection of tutorials and guides on setting up your CI/CD pipeline for various programming languages, frameworks, +and operating systems. ## Integrations -- **Articles:** - - [Continuous Delivery with GitLab and Convox](https://about.gitlab.com/2016/06/09/continuous-delivery-with-gitlab-and-convox/) - - [Getting Started with GitLab and Shippable Continuous Integration](https://about.gitlab.com/2016/05/05/getting-started-gitlab-and-shippable/) - - [GitLab Partners with DigitalOcean to make Continuous Integration faster, safer, and more affordable](https://about.gitlab.com/2016/04/19/gitlab-partners-with-digitalocean-to-make-continuous-integration-faster-safer-and-more-affordable/) +- Article (2016-06-09): [Continuous Delivery with GitLab and Convox](https://about.gitlab.com/2016/06/09/continuous-delivery-with-gitlab-and-convox/) +- Article (2016-05-05): [Getting Started with GitLab and Shippable Continuous Integration](https://about.gitlab.com/2016/05/05/getting-started-gitlab-and-shippable/) +- Article (2016-04-19): [GitLab Partners with DigitalOcean to make Continuous Integration faster, safer, and more affordable](https://about.gitlab.com/2016/04/19/gitlab-partners-with-digitalocean-to-make-continuous-integration-faster-safer-and-more-affordable/) -## Why GitLab CI? +## Special configuration (GitLab admin) -- **Articles:** - - [Why We Chose GitLab CI for our CI/CD Solution](https://about.gitlab.com/2016/10/17/gitlab-ci-oohlala/) - - [Building our web-app on GitLab CI: 5 reasons why Captain Train migrated from Jenkins to GitLab CI](https://about.gitlab.com/2016/07/22/building-our-web-app-on-gitlab-ci/) +As a GitLab administrator, you can change the default behavior of GitLab CI/CD in +your whole GitLab instance as well as in each project. + +- [Continuous Integration admin settings](../administration/index.md#continuous-integration-settings) +- **Project specific:** + - [Pipelines settings](../user/project/pipelines/settings.md) + - [Learn how to enable or disable GitLab CI](enable_or_disable_ci.md) +- **Affecting the whole GitLab instance:** + - [Continuous Integration admin settings](../user/admin_area/settings/continuous_integration.md) ## Breaking changes diff --git a/doc/ci/autodeploy/index.md b/doc/ci/autodeploy/index.md index 474cb28b9e4..7102af5c529 100644 --- a/doc/ci/autodeploy/index.md +++ b/doc/ci/autodeploy/index.md @@ -37,6 +37,8 @@ during the deployment. We made a [simple guide](quick_start_guide.md) to using Auto Deploy with GitLab.com. +For a demonstration of GitLab Auto Deploy, read the blog post [Auto Deploy from GitLab to an OpenShift Container Cluster](https://about.gitlab.com/2017/05/16/devops-containers-gitlab-openshift/) + ## Supported templates The list of supported auto deploy templates is available in the diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md index d4590d0f495..0109e77935a 100644 --- a/doc/ci/examples/README.md +++ b/doc/ci/examples/README.md @@ -2,81 +2,72 @@ comments: false --- -# GitLab CI Examples +# GitLab CI/CD Examples -A collection of `.gitlab-ci.yml` files is maintained at the [GitLab CI Yml project][gitlab-ci-templates]. -If your favorite programming language or framework are missing we would love your help by sending a merge request -with a `.gitlab-ci.yml`. +A collection of `.gitlab-ci.yml` template files is maintained at the [GitLab CI/CD YAML project][gitlab-ci-templates]. When you create a new file via the UI, +GitLab will give you the option to choose one of the templates existent on this project. +If your favorite programming language or framework are missing we would love your +help by sending a merge request with a new `.gitlab-ci.yml` to this project. -Apart from those, here is an collection of tutorials and guides on setting up your CI pipeline: +There's also a collection of repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork an adjust them to your own needs. ## Languages, frameworks, OSs -### PHP +- **PHP**: + - [Testing a PHP application](php.md) + - [Run PHP Composer & NPM scripts then deploy them to a staging server](deployment/composer-npm-deploy.md) + - [How to test and deploy Laravel/PHP applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md) +- **Ruby**: [Test and deploy a Ruby application to Heroku](test-and-deploy-ruby-application-to-heroku.md) +- **Python**: [Test and deploy a Python application to Heroku](test-and-deploy-python-application-to-heroku.md) +- **Java**: [Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/) +- **Scala**: [Test a Scala application](test-scala-application.md) +- **Clojure**: [Test a Clojure application](test-clojure-application.md) +- **Elixir**: + - [Test a Phoenix application](test-phoenix-application.md) + - [Building an Elixir Release into a Docker image using GitLab CI](https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/) +- **iOS and macOS**: + - [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/) + - [How to use GitLab CI and MacStadium to build your macOS or iOS projects](https://about.gitlab.com/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/) +- **Android**: [Setting up GitLab CI for Android projects](https://about.gitlab.com/2016/11/30/setting-up-gitlab-ci-for-android-projects/) +- **Debian**: [Continuous Deployment with GitLab: how to build and deploy a Debian Package with GitLab CI](https://about.gitlab.com/2016/10/12/automated-debian-package-build-with-gitlab-ci/) +- **Maven**: [How to deploy Maven projects to Artifactory with GitLab CI/CD](artifactory_and_gitlab/index.md) + +### Miscellaneous -- [Testing a PHP application](php.md) -- [Run PHP Composer & NPM scripts then deploy them to a staging server](deployment/composer-npm-deploy.md) -- [How to test and deploy Laravel/PHP applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md) - -### Ruby - -- [Test and deploy a Ruby application to Heroku](test-and-deploy-ruby-application-to-heroku.md) - -### Python - -- [Test and deploy a Python application to Heroku](test-and-deploy-python-application-to-heroku.md) - -### Java - -- [Continuous Delivery of a Spring Boot application with GitLab CI and Kubernetes](https://about.gitlab.com/2016/12/14/continuous-delivery-of-a-spring-boot-application-with-gitlab-ci-and-kubernetes/) - -### Scala - -- [Test a Scala application](test-scala-application.md) - -### Clojure - -- [Test a Clojure application](test-clojure-application.md) - -### Elixir +- [Using `dpl` as deployment tool](deployment/README.md) +- [The `.gitlab-ci.yml` file for GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml) -- [Test a Phoenix application](test-phoenix-application.md) -- [Building an Elixir Release into a Docker image using GitLab CI](https://about.gitlab.com/2016/08/11/building-an-elixir-release-into-docker-image-using-gitlab-ci-part-1/) +### Code quality analysis -### iOS +[Analyze code quality with the Code Climate CLI](code_climate.md). -- [Setting up GitLab CI for iOS projects](https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/) +### Static Application Security Testing (SAST) -### Android +- **(EEU)** [Scan your code for vulnerabilities](https://docs.gitlab.com/ee/ci/examples/sast.html) +- [Scan your Docker images for vulnerabilities](sast_docker.md) -- [Setting up GitLab CI for Android projects](https://about.gitlab.com/2016/11/30/setting-up-gitlab-ci-for-android-projects/) +### Dynamic Application Security Testing (DAST) -### Code quality analysis +Scan your app for vulnerabilities with GitLab [Dynamic Application Security Testing (DAST)](dast.md). -- [Analyze code quality with the Code Climate CLI](code_climate.md) +### Browser Performance Testing with Sitespeed.io -### Other +Analyze your [browser performance with Sitespeed.io](browser_performance.md). -- [Using `dpl` as deployment tool](deployment/README.md) -- [Repositories with examples for various languages](https://gitlab.com/groups/gitlab-examples) -- [The .gitlab-ci.yml file for GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml) -- [Continuous Deployment with GitLab: how to build and deploy a Debian Package with GitLab CI](https://about.gitlab.com/2016/10/12/automated-debian-package-build-with-gitlab-ci/) -- [How to deploy Maven projects to Artifactory with GitLab CI/CD](artifactory_and_gitlab/index.md) +### GitLab CI/CD for Review Apps -## GitLab CI/CD for GitLab Pages +- [Example project](https://gitlab.com/gitlab-examples/review-apps-nginx/) that shows how to use GitLab CI/CD for [Review Apps](../review_apps/index.html). +- [Dockerizing GitLab Review Apps](https://about.gitlab.com/2017/07/11/dockerizing-review-apps/) -- [Example projects](https://gitlab.com/pages) -- [Creating and Tweaking `.gitlab-ci.yml` for GitLab Pages](../../user/project/pages/getting_started_part_four.md) -- [SSGs Part 3: Build any SSG site with GitLab Pages](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/): -examples for Ruby-, NodeJS-, Python-, and GoLang-based SSGs -- [Building a new GitLab docs site with Nanoc, GitLab CI, and GitLab Pages](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) -- [Publish code coverage reports with GitLab Pages](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/) +### GitLab CI/CD for GitLab Pages See the documentation on [GitLab Pages](../../user/project/pages/index.md) for a complete overview. -## More +## Contributing -Contributions are very much welcomed! You can help your favorite programming -language and GitLab by sending a merge request with a guide for that language. +Contributions are very welcome! You can help your favorite programming +language users and GitLab by sending a merge request with a guide for that language. +You may want to apply for the [GitLab Community Writers Program](https://about.gitlab.com/community-writers/) +to get paid for writing complete articles for GitLab. [gitlab-ci-templates]: https://gitlab.com/gitlab-org/gitlab-ci-yml diff --git a/doc/ci/examples/dast.md b/doc/ci/examples/dast.md new file mode 100644 index 00000000000..16ff8d5bb3e --- /dev/null +++ b/doc/ci/examples/dast.md @@ -0,0 +1,35 @@ +# Dynamic Application Security Testing with GitLab CI/CD + +This example shows how to run +[Dynamic Application Security Testing (DAST)](https://en.wikipedia.org/wiki/Dynamic_program_analysis) +on your project's source code by using GitLab CI/CD. + +DAST is using the popular open source tool +[OWASP ZAProxy](https://github.com/zaproxy/zaproxy) to perform an analysis. + +All you need is a GitLab Runner with the Docker executor (the shared Runners on +GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`, +called `dast`: + +```yaml +dast: + image: owasp/zap2docker-stable + script: + - mkdir /zap/wrk/ + - /zap/zap-baseline.py -J gl-dast-report.json -t https://example.com || true + - cp /zap/wrk/gl-dast-report.json . + artifacts: + paths: [gl-dast-report.json] +``` + +The above example will create a `dast` job in your CI pipeline and will allow +you to download and analyze the report artifact in JSON format. + +TIP: **Tip:** +Starting with [GitLab Enterprise Edition Ultimate][ee] 10.4, this information will +be automatically extracted and shown right in the merge request widget. To do +so, the CI job must be named `dast` and the artifact path must be +`gl-dast-report.json`. +[Learn more on dynamic application security testing results shown in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html). + +[ee]: https://about.gitlab.com/gitlab-ee/ diff --git a/doc/ci/examples/sast_docker.md b/doc/ci/examples/sast_docker.md new file mode 100644 index 00000000000..d99cfe93afa --- /dev/null +++ b/doc/ci/examples/sast_docker.md @@ -0,0 +1,55 @@ +# Static Application Security Testing for Docker containers with GitLab CI/CD + +You can check your Docker images (or more precisely the containers) for known +vulnerabilities by using [Clair](https://github.com/coreos/clair) and +[clair-scanner](https://github.com/arminc/clair-scanner), two open source tools +for Vulnerability Static Analysis for containers. + +All you need is a GitLab Runner with the Docker executor (the shared Runners on +GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`, +called `sast:container`: + +```yaml +sast:container: + image: docker:latest + variables: + DOCKER_DRIVER: overlay2 + ## Define two new variables based on GitLab's CI/CD predefined variables + ## https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables + CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG + CI_APPLICATION_TAG: $CI_COMMIT_SHA + allow_failure: true + services: + - docker:dind + script: + - docker run -d --name db arminc/clair-db:latest + - docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.1 + - apk add -U wget ca-certificates + - docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} + - wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64 + - mv clair-scanner_linux_amd64 clair-scanner + - chmod +x clair-scanner + - touch clair-whitelist.yml + - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-sast-container-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true + artifacts: + paths: [gl-sast-container-report.json] +``` + +The above example will create a `sast:container` job in your CI/CD pipeline, pull +the image from the [Container Registry](../../user/project/container_registry.md) +(whose name is defined from the two `CI_APPLICATION_` variables) and scan it +for possible vulnerabilities. The report will be saved as an artifact that you +can later download and analyze. + +If you want to whitelist some specific vulnerabilities, you can do so by defining +them in a [YAML file](https://github.com/arminc/clair-scanner/blob/master/README.md#example-whitelist-yaml-file), +in our case its named `clair-whitelist.yml`. + +TIP: **Tip:** +Starting with [GitLab Enterprise Edition Ultimate][ee] 10.4, this information will +be automatically extracted and shown right in the merge request widget. To do +so, the CI/CD job must be named `sast:container` and the artifact path must be +`gl-sast-container-report.json`. +[Learn more on application security testing results shown in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/sast_docker.html). + +[ee]: https://about.gitlab.com/gitlab-ee/ diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md index 10fd2616fab..7f9ab1f3a5e 100644 --- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md +++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md @@ -10,6 +10,7 @@ This is what the `.gitlab-ci.yml` file looks like for this project: ```yaml test: + stage: test script: - apt-get update -qy - apt-get install -y nodejs @@ -18,7 +19,7 @@ test: - bundle exec rake test staging: - type: deploy + stage: deploy script: - gem install dpl - dpl --provider=heroku --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY @@ -26,7 +27,7 @@ staging: - master production: - type: deploy + stage: deploy script: - gem install dpl - dpl --provider=heroku --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 32464cbb259..ae0b5c0a2ba 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -93,7 +93,7 @@ be an array or a multi-line string. > Introduced in GitLab 8.7 and requires Gitlab Runner v1.2 `after_script` is used to define the command that will be run after for all -jobs. This has to be an array or a multi-line string. +jobs, including failed ones. This has to be an array or a multi-line string. > **Note:** The `before_script` and the main `script` are concatenated and run in a single context/container. diff --git a/doc/development/doc_styleguide.md b/doc/development/doc_styleguide.md index 9cb1f708a6a..f41d31797af 100644 --- a/doc/development/doc_styleguide.md +++ b/doc/development/doc_styleguide.md @@ -34,7 +34,6 @@ The table below shows what kind of documentation goes where. | `doc/install/`| Probably the most visited directory, since `installation.md` is there. Ideally this should go under `doc/administration/`, but it's best to leave it as-is in order to avoid confusion (still debated though). | | `doc/update/` | Same with `doc/install/`. Should be under `administration/`, but this is a well known location, better leave as-is, at least for now. | | `doc/topics/` | Indexes per Topic (`doc/topics/topic-name/index.md`): all resources for that topic (user and admin documentation, articles, and third-party docs) | -| `doc/articles/` | [Technical Articles](writing_documentation.md#technical-articles): user guides, admin guides, technical overviews, tutorials (`doc/articles/article-title/index.md`). | --- @@ -67,11 +66,10 @@ The table below shows what kind of documentation goes where. 1. The `doc/topics/` directory holds topic-related technical content. Create `doc/topics/topic-name/subtopic-name/index.md` when subtopics become necessary. General user- and admin- related documentation, should be placed accordingly. -1. For technical articles, place their images under `doc/articles/article-title/img/`. --- -If you are unsure where a document should live, you can ping `@axil` in your +If you are unsure where a document should live, you can ping `@axil` or `@marcia` in your merge request. ## Text @@ -108,8 +106,8 @@ merge request. - Avoid adding things that show ephemeral statuses. For example, if a feature is considered beta or experimental, put this info in a note, not in the heading. - When introducing a new document, be careful for the headings to be - grammatically and syntactically correct. It is advised to mention one or all - of the following GitLab members for a review: `@axil`, `@rspeicher`, `@marcia`. + grammatically and syntactically correct. Mention one or all + of the following GitLab members for a review: `@axil` or `@marcia`. This is to ensure that no document with wrong heading is going live without an audit, thus preventing dead links and redirection issues when corrected @@ -203,7 +201,7 @@ You can combine one or more of the following: - Keep all file names in lower case. - Consider using PNG images instead of JPEG. - Compress all images with <https://tinypng.com/> or similar tool. -- Compress gifs with <https://ezgif.com/optimize> or similar toll. +- Compress gifs with <https://ezgif.com/optimize> or similar tool. - Images should be used (only when necessary) to _illustrate_ the description of a process, not to _replace_ it. @@ -330,6 +328,10 @@ For example, if you were to move `doc/workflow/lfs/lfs_administration.md` to git grep -n "lfs/lfs_administration" ``` +NOTE: **Note:** +If the document being moved has any Disqus comments on it, there are extra steps +to follow documented just [below](#redirections-for-pages-with-disqus-comments). + Things to note: - Since we also use inline documentation, except for the documentation itself, @@ -342,6 +344,32 @@ Things to note: documentation, sometimes it might be useful to search a path deeper. - The `*.md` extension is not used when a document is linked to GitLab's built-in help page, that's why we omit it in `git grep`. +- Use the checklist on the documentation MR description template. + +### Redirections for pages with Disqus comments + +If the documentation page being relocated already has any Disqus comments, +we need to preserve the Disqus thread. + +Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier +is configured to be the page URL. Therefore, when we change the document location, +we need to preserve the old URL as the same Disqus identifier. + +To do that, add to the frontmatter the variable `redirect_from`, +using the old URL as value. For example, let's say I moved the document +available under `https://docs.gitlab.com/my-old-location/README.html` to a new location, +`https://docs.gitlab.com/my-new-location/index.html`. + +Into the **new document** frontmatter add the following: + +```yaml +--- +redirect_from: 'https://docs.gitlab.com/my-old-location/README.html' +--- +``` + +Note: it is necessary to include the file name in the `redirect_from` URL, +even if it's `index.html` or `README.html`. ## Configuration documentation for source and Omnibus installations diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 1af839a27e1..f8cee89e650 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -87,9 +87,9 @@ still having access the class's implementation with `super`. There are a few gotchas with it: -- you should always add a `raise NotImplementedError unless defined?(super)` - guard clause in the "overrider" method to ensure that if the method gets - renamed in CE, the EE override won't be silently forgotten. +- you should always [`extend ::Gitlab::Utils::Override`] and use `override` to + guard the "overrider" method to ensure that if the method gets renamed in + CE, the EE override won't be silently forgotten. - when the "overrider" would add a line in the middle of the CE implementation, you should refactor the CE method and split it in smaller methods. Or create a "hook" method that is empty in CE, @@ -134,6 +134,9 @@ There are a few gotchas with it: guards: ``` ruby module EE::Base + extend ::Gitlab::Utils::Override + + override :do_something def do_something # Follow the above pattern to call super and extend it end @@ -174,10 +177,11 @@ implementation: ```ruby module EE - class ApplicationController - def after_sign_out_path_for(resource) - raise NotImplementedError unless defined?(super) + module ApplicationController + extend ::Gitlab::Utils::Override + override :after_sign_out_path_for + def after_sign_out_path_for(resource) if Gitlab::Geo.secondary? Gitlab::Geo.primary_node.oauth_logout_url(@geo_logout_state) else @@ -188,6 +192,8 @@ module EE end ``` +[`extend ::Gitlab::Utils::Override`]: utilities.md#override + #### Use self-descriptive wrapper methods When it's not possible/logical to modify the implementation of a @@ -208,8 +214,8 @@ end In EE, the implementation `ee/app/models/ee/users.rb` would be: ```ruby +override :full_private_access? def full_private_access? - raise NotImplementedError unless defined?(super) super || auditor? end ``` diff --git a/doc/development/utilities.md b/doc/development/utilities.md index 951c3ef85ce..8f9aff1a35f 100644 --- a/doc/development/utilities.md +++ b/doc/development/utilities.md @@ -45,6 +45,51 @@ We developed a number of utilities to ease development. [:hello, "world", :this, :crushes, "an entire", "hash"] ``` +## [`Override`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/override.rb) + +* This utility could help us check if a particular method would override + another method or not. It has the same idea of Java's `@Override` annotation + or Scala's `override` keyword. However we only do this check when + `ENV['STATIC_VERIFICATION']` is set to avoid production runtime overhead. + This is useful to check: + + * If we have typos in overriding methods. + * If we renamed the overridden methods, making original overriding methods + overrides nothing. + + Here's a simple example: + + ``` ruby + class Base + def execute + end + end + + class Derived < Base + extend ::Gitlab::Utils::Override + + override :execute # Override check happens here + def execute + end + end + ``` + + This also works on modules: + + ``` ruby + module Extension + extend ::Gitlab::Utils::Override + + override :execute # Modules do not check this immediately + def execute + end + end + + class Derived < Base + prepend Extension # Override check happens here, not in the module + end + ``` + ## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/strong_memoize.rb) * Memoize the value even if it is `nil` or `false`. diff --git a/doc/development/writing_documentation.md b/doc/development/writing_documentation.md index 133ac0234cf..2a1d744668b 100644 --- a/doc/development/writing_documentation.md +++ b/doc/development/writing_documentation.md @@ -25,6 +25,26 @@ them to review it for you. We use the [monthly release blog post](https://about.gitlab.com/handbook/marketing/blog/release-posts/#monthly-releases) as a changelog checklist to ensure everything is documented. +Whenever you submit a merge request for the documentation, use the documentation MR description template. + +### Documentation directory structure + +The documentation is structured based on the GitLab UI structure itself, +separated by [`user`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/user), +[`administrator`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/administration), and [`contributor`](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/development). + +To learn where to place a new document, check the [documentation style guide](doc_styleguide.md#location-and-naming-of-documents). + +In order to have a [solid site structure](https://searchengineland.com/seo-benefits-developing-solid-site-structure-277456) for our documentation, +all docs should be linked. Every new document should be cross-linked to its related documentation, and linked from its topic-related index, when existent. + +The directories `/workflow/`, `/gitlab-basics/`, `/university/`, and `/articles/` have +been deprecated and the majority their docs have been moved to their correct location +in small iterations. Please don't create new docs in these folders. + +To move a document from its location to another directory, read the section +[changing document location](doc_styleguide.md#changing-document-location) of the doc style guide. + ### Feature overview and use cases Every major feature (regardless if present in GitLab Community or Enterprise editions) diff --git a/doc/install/README.md b/doc/install/README.md index 43197351db3..87f6969b415 100644 --- a/doc/install/README.md +++ b/doc/install/README.md @@ -25,15 +25,19 @@ the hardware requirements. ## Install GitLab on cloud providers -- [Installing in Kubernetes](kubernetes/index.md) - Install GitLab into a Kubernetes +- [Installing in Kubernetes](kubernetes/index.md): Install GitLab into a Kubernetes Cluster using our official Helm Chart Repository. - [Install GitLab on OpenShift](openshift_and_gitlab/index.md) - [Install GitLab on DC/OS](https://mesosphere.com/blog/gitlab-dcos/) via [GitLab-Mesosphere integration](https://about.gitlab.com/2016/09/16/announcing-gitlab-and-mesosphere/) - [Install GitLab on Azure](azure/index.md) - [Install GitLab on Google Cloud Platform](google_cloud_platform/index.md) +- [Install GitLab on Google Container Engine (GKE)](https://about.gitlab.com/2017/01/23/video-tutorial-idea-to-production-on-google-container-engine-gke/): video tutorial on +the full process of installing GitLab on Google Container Engine (GKE), pushing an application to GitLab, building the app with GitLab CI/CD, and deploying to production. - [Install on AWS](https://about.gitlab.com/aws/) - _Testing only!_ [DigitalOcean and Docker Machine](digitaloceandocker.md) - Quickly test any version of GitLab on DigitalOcean using Docker Machine. +- [Getting started with GitLab and DigitalOcean](ttps://about.gitlab.com/2016/04/27/getting-started-with-gitlab-and-digitalocean/): requirements, installation process, updates. +- [Demo: Cloud Native Development with GitLab](https://about.gitlab.com/2017/04/18/cloud-native-demo/): video demonstration on how to install GitLab on Kubernetes, build a project, create Review Apps, store Docker images in Container Registry, deploy to production on Kubernetes, and monitor with Prometheus. ## Database diff --git a/doc/install/openshift_and_gitlab/index.md b/doc/install/openshift_and_gitlab/index.md index 8fba44aea02..448cbe1077d 100644 --- a/doc/install/openshift_and_gitlab/index.md +++ b/doc/install/openshift_and_gitlab/index.md @@ -15,6 +15,8 @@ In this tutorial, we will see how to deploy GitLab in OpenShift using GitLab's official Docker image while getting familiar with the web interface and CLI tools that will help us achieve our goal. +For a video demonstration on installing GitLab on Openshift, check the article [In 13 minutes from Kubernetes to a complete application development tool](https://about.gitlab.com/2016/11/14/idea-to-production/). + --- ## Prerequisites diff --git a/doc/system_hooks/system_hooks.md b/doc/system_hooks/system_hooks.md index f2a9b1d769b..8c8501bcc23 100644 --- a/doc/system_hooks/system_hooks.md +++ b/doc/system_hooks/system_hooks.md @@ -11,6 +11,7 @@ Your GitLab instance can perform HTTP POST requests on the following events: - `user_remove_from_team` - `user_create` - `user_destroy` +- `user_failed_login` - `user_rename` - `key_create` - `key_destroy` @@ -22,6 +23,8 @@ Your GitLab instance can perform HTTP POST requests on the following events: The triggers for most of these are self-explanatory, but `project_update` and `project_rename` deserve some clarification: `project_update` is fired any time an attribute of a project is changed (name, description, tags, etc.) *unless* the `path` attribute is also changed. In that case, a `project_rename` is triggered instead (so that, for instance, if all you care about is the repo URL, you can just listen for `project_rename`). +`user_failed_login` is sent whenever a **blocked** user attempts to login and denied access. + System hooks can be used, e.g. for logging or changing information in a LDAP server. > **Note:** @@ -196,6 +199,23 @@ Please refer to `group_rename` and `user_rename` for that case. } ``` +**User failed login:** + +```json +{ + "event_name": "user_failed_login", + "created_at": "2017-10-03T06:08:48Z", + "updated_at": "2018-01-15T04:52:06Z", + "name": "John Smith", + "email": "user4@example.com", + "user_id": 26, + "username": "user4", + "state": "blocked" +} +``` + +If the user is blocked via LDAP, `state` will be `ldap_blocked`. + **User renamed:** ```json diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index e23c73f46fb..6ad314647ee 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -20,6 +20,8 @@ project in an easy and automatic way: 1. [Auto Test](#auto-test) 1. [Auto Code Quality](#auto-code-quality) 1. [Auto SAST (Static Application Security Testing)](#auto-sast) +1. [Auto SAST for Docker images](#auto-sast-for-docker-images) +1. [Auto DAST (Dynamic Application Security Testing)](#auto-dast) 1. [Auto Browser Performance Testing](#auto-browser-performance-testing) 1. [Auto Review Apps](#auto-review-apps) 1. [Auto Deploy](#auto-deploy) @@ -37,6 +39,8 @@ knowledge of the following: Auto DevOps provides great defaults for all the stages; you can, however, [customize](#customizing) almost everything to your needs. +For an overview on the creation of Auto DevOps, read the blog post [From 2/3 of the Self-Hosted Git Market, to the Next-Generation CI System, to Auto DevOps](https://about.gitlab.com/2017/06/29/whats-next-for-gitlab-ci/). + ## Prerequisites TIP: **Tip:** @@ -193,8 +197,10 @@ Auto Code Quality uses the open source [`codeclimate` image](https://hub.docker.com/r/codeclimate/codeclimate/) to run static analysis and other code checks on the current code. The report is created, and is uploaded as an artifact which you can later download and check -out. In GitLab Enterprise Edition Starter, differences between the source and -target branches are +out. + +In GitLab Enterprise Edition Starter, differences between the source and +target branches are also [shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html). ### Auto SAST @@ -207,7 +213,34 @@ analysis on the current code and checks for potential security issues. Once the report is created, it's uploaded as an artifact which you can later download and check out. -Any security warnings are also [shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/sast.html). +In GitLab Enterprise Edition Ultimate, any security warnings are also +[shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/sast.html). + +### Auto SAST for Docker images + +> Introduced in GitLab 10.4. + +Vulnerability Static Analysis for containers uses +[Clair](https://github.com/coreos/clair) to run static analysis on a +Docker image and checks for potential security issues. Once the report is +created, it's uploaded as an artifact which you can later download and +check out. + +In GitLab Enterprise Edition Ultimate, any security warnings are also +[shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/sast_docker.html). + +### Auto DAST + +> Introduced in [GitLab Enterprise Edition Ultimate][ee] 10.4. + +Dynamic Application Security Testing (DAST) uses the +popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy) +to perform an analysis on the current code and checks for potential security +issues. Once the report is created, it's uploaded as an artifact which you can +later download and check out. + +In GitLab Enterprise Edition Ultimate, any security warnings are also +[shown in the merge request widget](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html). ### Auto Browser Performance Testing diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md index f69e2e49f0c..2ca2bf743fb 100644 --- a/doc/topics/git/index.md +++ b/doc/topics/git/index.md @@ -44,7 +44,7 @@ We've gathered some resources to help you to get the best from Git with GitLab. ## Troubleshooting Git -- [Numerous _undo_ possibilities in Git](../../articles/numerous_undo_possibilities_in_git/index.md) +- [Numerous _undo_ possibilities in Git](numerous_undo_possibilities_in_git/index.md) - Learn a few [Git troubleshooting](troubleshooting_git.md) techniques to help you out. ## Branching strategies diff --git a/doc/articles/numerous_undo_possibilities_in_git/img/branching.png b/doc/topics/git/numerous_undo_possibilities_in_git/img/branching.png Binary files differindex 9a80c211c99..9a80c211c99 100644 --- a/doc/articles/numerous_undo_possibilities_in_git/img/branching.png +++ b/doc/topics/git/numerous_undo_possibilities_in_git/img/branching.png diff --git a/doc/articles/numerous_undo_possibilities_in_git/img/rebase_reset.png b/doc/topics/git/numerous_undo_possibilities_in_git/img/rebase_reset.png Binary files differindex ac7ea9ecddc..ac7ea9ecddc 100644 --- a/doc/articles/numerous_undo_possibilities_in_git/img/rebase_reset.png +++ b/doc/topics/git/numerous_undo_possibilities_in_git/img/rebase_reset.png diff --git a/doc/articles/numerous_undo_possibilities_in_git/img/revert.png b/doc/topics/git/numerous_undo_possibilities_in_git/img/revert.png Binary files differindex 13b3a35ca45..13b3a35ca45 100644 --- a/doc/articles/numerous_undo_possibilities_in_git/img/revert.png +++ b/doc/topics/git/numerous_undo_possibilities_in_git/img/revert.png diff --git a/doc/topics/git/numerous_undo_possibilities_in_git/index.md b/doc/topics/git/numerous_undo_possibilities_in_git/index.md new file mode 100644 index 00000000000..6a2f7b30dd3 --- /dev/null +++ b/doc/topics/git/numerous_undo_possibilities_in_git/index.md @@ -0,0 +1,497 @@ +# Numerous undo possibilities in Git + +> **[Article Type](../../../development/writing_documentation.md#types-of-technical-articles):** tutorial || +> **Level:** intermediary || +> **Author:** [Crt Mori](https://gitlab.com/Letme) || +> **Publication date:** 2017-08-17 + +## Introduction + +In this tutorial, we will show you different ways of undoing your work in Git, for which +we will assume you have a basic working knowledge of. Check GitLab's +[Git documentation](../index.md#git-documentation) for reference. +Also, we will only provide some general info of the commands, which is enough +to get you started for the easy cases/examples, but for anything more advanced please refer to the [Git book](https://git-scm.com/book/en/v2). + +We will explain a few different techniques to undo your changes based on the stage +of the change in your current development. Also, keep in mind that [nothing in +Git is really deleted.][git-autoclean-ref] +This means that until Git automatically cleans detached commits (which cannot be +accessed by branch or tag) it will be possible to view them with `git reflog` command +and access them with direct commit-id. Read more about _[redoing the undo](#redoing-the-undo)_ on the section below. + +This guide is organized depending on the [stage of development][git-basics] +where you want to undo your changes from and if they were shared with other developers +or not. Because Git is tracking changes a created or edited file is in the unstaged state +(if created it is untracked by Git). After you add it to a repository (`git add`) you put +a file into the **staged** state, which is then committed (`git commit`) to your +local repository. After that, file can be shared with other developers (`git push`). +Here's what we'll cover in this tutorial: + + - [Undo local changes](#undo-local-changes) which were not pushed to remote repository + + - Before you commit, in both unstaged and staged state + - After you committed + + - Undo changes after they are pushed to remote repository + + - [Without history modification](#undo-remote-changes-without-changing-history) (preferred way) + - [With history modification](#undo-remote-changes-with-modifying-history) (requires + coordination with team and force pushes). + + - [Usecases when modifying history is generally acceptable](#where-modifying-history-is-generally-acceptable) + - [How to modify history](#how-modifying-history-is-done) + - [How to remove sensitive information from repository](#deleting-sensitive-information-from-commits) + + +### Branching strategy + +[Git][git-official] is a de-centralized version control system, which means that beside regular +versioning of the whole repository, it has possibilities to exchange changes +with other repositories. To avoid chaos with +[multiple sources of truth][git-distributed], various +development workflows have to be followed, and it depends on your internal +workflow how certain changes or commits can be undone or changed. +[GitLab Flow][gitlab-flow] provides a good +balance between developers clashing with each other while +developing the same feature and cooperating seamlessly, but it does not enable +joined development of the same feature by multiple developers by default. +When multiple developers develop the same feature on the same branch, clashing +with every synchronization is unavoidable, but a proper or chosen Git Workflow will +prevent that anything is lost or out of sync when feature is complete. You can also +read through this blog post on [Git Tips & Tricks][gitlab-git-tips-n-tricks] +to learn how to easily **do** things in Git. + + +## Undo local changes + +Until you push your changes to any remote repository, they will only affect you. +That broadens your options on how to handle undoing them. Still, local changes +can be on various stages and each stage has a different approach on how to tackle them. + + +### Unstaged local changes (before you commit) + +When a change is made, but it is not added to the staged tree, Git itself +proposes a solution to discard changes to certain file. + +Suppose you edited a file to change the content using your favorite editor: + +```shell +vim <file> +``` + +Since you did not `git add <file>` to staging, it should be under unstaged files (or +untracked if file was created). You can confirm that with: + +```shell +$ git status +On branch master +Your branch is up-to-date with 'origin/master'. +Changes not staged for commit: + (use "git add <file>..." to update what will be committed) + (use "git checkout -- <file>..." to discard changes in working directory) + + modified: <file> +no changes added to commit (use "git add" and/or "git commit -a") +``` + +At this point there are 3 options to undo the local changes you have: + + - Discard all local changes, but save them for possible re-use [later](#quickly-save-local-changes) + + ```shell + git stash + ``` + + - Discarding local changes (permanently) to a file + + ```shell + git checkout -- <file> + ``` + + - Discard all local changes to all files permanently + + ```shell + git reset --hard + ``` + + +Before executing `git reset --hard`, keep in mind that there is also a way to +just temporary store the changes without committing them using `git stash`. +This command resets the changes to all files, but it also saves them in case +you would like to apply them at some later time. You can read more about it in +[section below](#quickly-save-local-changes). + +### Quickly save local changes + +You are working on a feature when a boss drops by with an urgent task. Since your +feature is not complete, but you need to swap to another branch, you can use +`git stash` to save what you had done, swap to another branch, commit, push, +test, then get back to previous feature branch, do `git stash pop` and continue +where you left. + +The example above shows that discarding all changes is not always a preferred option, +but Git provides a way to save them for later, while resetting the repository to state without +them. This is achieved by Git stashing command `git stash`, which in fact saves your +current work and runs `git reset --hard`, but it also has various +additional options like: + + - `git stash save`, which enables including temporary commit message, which will help you identify changes, among with other options + - `git stash list`, which lists all previously stashed commits (yes, there can be more) that were not `pop`ed + - `git stash pop`, which redoes previously stashed changes and removes them from stashed list + - `git stash apply`, which redoes previously stashed changes, but keeps them on stashed list + +### Staged local changes (before you commit) + +Let's say you have added some files to staging, but you want to remove them from the +current commit, yet you want to retain those changes - just move them outside +of the staging tree. You also have an option to discard all changes with +`git reset --hard` or think about `git stash` [as described earlier.](#quickly-save-local-changes) + +Lets start the example by editing a file, with your favorite editor, to change the +content and add it to staging + +``` +vim <file> +git add <file> +``` + +The file is now added to staging as confirmed by `git status` command: + +```shell +$ git status +On branch master +Your branch is up-to-date with 'origin/master'. +Changes to be committed: + (use "git reset HEAD <file>..." to unstage) + + new file: <file> +``` + +Now you have 4 options to undo your changes: + + - Unstage the file to current commit (HEAD) + + ```shell + git reset HEAD <file> + ``` + + - Unstage everything - retain changes + + ```shell + git reset + ``` + + - Discard all local changes, but save them for [later](#quickly-save-local-changes) + + ```shell + git stash + ``` + + - Discard everything permanently + + ```shell + git reset --hard + ``` + +## Committed local changes + +Once you commit, your changes are recorded by the version control system. +Because you haven't pushed to your remote repository yet, your changes are +still not public (or shared with other developers). At this point, undoing +things is a lot easier, we have quite some workaround options. Once you push +your code, you'll have less options to troubleshoot your work. + +### Without modifying history + +Through the development process some of the previously committed changes do not +fit anymore in the end solution, or are source of the bugs. Once you find the +commit which triggered bug, or once you have a faulty commit, you can simply +revert it with `git revert commit-id`. This command inverts (swaps) the additions and +deletions in that commit, so that it does not modify history. Retaining history +can be helpful in future to notice that some changes have been tried +unsuccessfully in the past. + +In our example we will assume there are commits `A`,`B`,`C`,`D`,`E` committed in this order: `A-B-C-D-E`, +and `B` is the commit you want to undo. There are many different ways to identify commit +`B` as bad, one of them is to pass a range to `git bisect` command. The provided range includes +last known good commit (we assume `A`) and first known bad commit (where bug was detected - we will assume `E`). + +```shell +git bisect A..E +``` + +Bisect will provide us with commit-id of the middle commit to test, and then guide us +through simple bisection process. You can read more about it [in official Git Tools][git-debug] +In our example we will end up with commit `B`, that introduced bug/error. We have +4 options on how to remove it (or part of it) from our repository. + +- Undo (swap additions and deletions) changes introduced by commit `B`. + + ```shell + git revert commit-B-id + ``` + +- Undo changes on a single file or directory from commit `B`, but retain them in the staged state + + ```shell + git checkout commit-B-id <file> + ``` + +- Undo changes on a single file or directory from commit `B`, but retain them in the unstaged state + + ```shell + git reset commit-B-id <file> + ``` + + - There is one command we also must not forget: **creating a new branch** + from the point where changes are not applicable or where the development has hit a + dead end. For example you have done commits `A-B-C-D` on your feature-branch + and then you figure `C` and `D` are wrong. At this point you either reset to `B` + and do commit `F` (which will cause problems with pushing and if forced pushed also with other developers) + since branch now looks `A-B-F`, which clashes with what other developers have locally (you will + [change history](#with-history-modification)), or you simply checkout commit `B` create + a new branch and do commit `F`. In the last case, everyone else can still do their work while you + have your new way to get it right and merge it back in later. Alternatively, with GitLab, + you can [cherry-pick](../../../user/project/merge_requests/cherry_pick_changes.md#cherry-picking-a-commit) + that commit into a new merge request. + +  + + ```shell + git checkout commit-B-id + git checkout -b new-path-of-feature + # Create <commit F> + git commit -a + ``` + +### With history modification + +There is one command for history modification and that is `git rebase`. Command +provides interactive mode (`-i` flag) which enables you to: + + - **reword** commit messages (there is also `git commit --amend` for editing + last commit message) + - **edit** the commit content (changes introduced by commit) and message + - **squash** multiple commits into a single one, and have a custom or aggregated + commit message + - **drop** commits - simply delete them + - and few more options + +Let us check few examples. Again there are commits `A-B-C-D` where you want to +delete commit `B`. + +- Rebase the range from current commit D to A: + + ```shell + git rebase -i A + ``` + +- Command opens your favorite editor where you write `drop` in front of commit + `B`, but you leave default `pick` with all other commits. Save and exit the + editor to perform a rebase. Remember: if you want to cancel delete whole + file content before saving and exiting the editor + +In case you want to modify something introduced in commit `B`. + +- Rebase the range from current commit D to A: + + ```shell + git rebase -i A + ``` + +- Command opens your favorite text editor where you write `edit` in front of commit + `B`, but leave default `pick` with all other commits. Save and exit the editor to + perform a rebase + +- Now do your edits and commit changes: + + ```shell + git commit -a + ``` + +You can find some more examples in [below section where we explain how to modify +history](#how-modifying-history-is-done) + + +### Redoing the Undo + +Sometimes you realize that the changes you undid were useful and you want them +back. Well because of first paragraph you are in luck. Command `git reflog` +enables you to *recall* detached local commits by referencing or applying them +via commit-id. Although, do not expect to see really old commits in reflog, because +Git regularly [cleans the commits which are *unreachable* by branches or tags][git-autoclean-ref]. + +To view repository history and to track older commits you can use below command: + +```shell +$ git reflog show + +# Example output: +b673187 HEAD@{4}: merge 6e43d5987921bde189640cc1e37661f7f75c9c0b: Merge made by the 'recursive' strategy. +eb37e74 HEAD@{5}: rebase -i (finish): returning to refs/heads/master +eb37e74 HEAD@{6}: rebase -i (pick): Commit C +97436c6 HEAD@{7}: rebase -i (start): checkout 97436c6eec6396c63856c19b6a96372705b08b1b +... +88f1867 HEAD@{12}: commit: Commit D +97436c6 HEAD@{13}: checkout: moving from 97436c6eec6396c63856c19b6a96372705b08b1b to test +97436c6 HEAD@{14}: checkout: moving from master to 97436c6 +05cc326 HEAD@{15}: commit: Commit C +6e43d59 HEAD@{16}: commit: Commit B +``` + +Output of command shows repository history. In first column there is commit-id, +in following column, number next to `HEAD` indicates how many commits ago something +was made, after that indicator of action that was made (commit, rebase, merge, ...) +and then on end description of that action. + +## Undo remote changes without changing history + +This topic is roughly same as modifying committed local changes without modifying +history. **It should be the preferred way of undoing changes on any remote repository +or public branch.** Keep in mind that branching is the best solution when you want +to retain the history of faulty development, yet start anew from certain point. Branching +enables you to include the existing changes in new development (by merging) and +it also provides a clear timeline and development structure. + + + +If you want to revert changes introduced in certain `commit-id` you can simply +revert that `commit-id` (swap additions and deletions) in newly created commit: +You can do this with + +```shell +git revert commit-id +``` + +or creating a new branch: + +```shell +git checkout commit-id +git checkout -b new-path-of-feature +``` + +## Undo remote changes with modifying history + +This is useful when you want to *hide* certain things - like secret keys, +passwords, SSH keys, etc. It is and should not be used to hide mistakes, as +it will make it harder to debug in case there are some other bugs. The main +reason for this is that you loose the real development progress. **Also keep in +mind that, even with modified history, commits are just detached and can still be +accessed through commit-id** - at least until all repositories perform +the cleanup of detached commits (happens automatically). + + + +### Where modifying history is generally acceptable + +Modified history breaks the development chain of other developers, as changed +history does not have matching commits'ids. For that reason it should not +be used on any public branch or on branch that *might* be used by other +developers. When contributing to big open source repositories (e.g. [GitLab CE][gitlab-ce]), +it is acceptable to *squash* commits into a single one, to present +a nicer history of your contribution. +Keep in mind that this also removes the comments attached to certain commits +in merge requests, so if you need to retain traceability in GitLab, then +modifying history is not acceptable. +A feature-branch of a merge request is a public branch and might be used by +other developers, but project process and rules might allow or require +you to use `git rebase` (command that changes history) to reduce number of +displayed commits on target branch after reviews are done (for example +GitLab). There is a `git merge --squash` command which does exactly that +(squashes commits on feature-branch to a single commit on target branch +at merge). + +>**Note:** +Never modify the commit history of `master` or shared branch + +### How modifying history is done + +After you know what you want to modify (how far in history or how which range of +old commits), use `git rebase -i commit-id`. This command will then display all the commits from +current version to chosen commit-id and allow modification, squashing, deletion +of that commits. + +```shell +$ git rebase -i commit1-id..commit3-id +pick <commit1-id> <commit1-commit-message> +pick <commit2-id> <commit2-commit-message> +pick <commit3-id> <commit3-commit-message> + +# Rebase commit1-id..commit3-id onto <commit4-id> (3 command(s)) +# +# Commands: +# p, pick = use commit +# r, reword = use commit, but edit the commit message +# e, edit = use commit, but stop for amending +# s, squash = use commit, but meld into previous commit +# f, fixup = like "squash", but discard this commit's log message +# x, exec = run command (the rest of the line) using shell +# d, drop = remove commit +# +# These lines can be re-ordered; they are executed from top to bottom. +# +# If you remove a line here THAT COMMIT WILL BE LOST. +# +# However, if you remove everything, the rebase will be aborted. +# +# Note that empty commits are commented out +``` + +>**Note:** +It is important to notice that comment from the output clearly states that, if +you decide to abort, then do not just close your editor (as that will in-fact +modify history), but remove all uncommented lines and save. + +That is one of the reasons why `git rebase` should be used carefully on +shared and remote branches. But don't worry, there will be nothing broken until +you push back to the remote repository (so you can freely explore the +different outcomes locally). + +```shell +# Modify history from commit-id to HEAD (current commit) +git rebase -i commit-id +``` + +### Deleting sensitive information from commits + +Git also enables you to delete sensitive information from your past commits and +it does modify history in the progress. That is why we have included it in this +section and not as a standalone topic. To do so, you should run the +`git filter-branch`, which enables you to rewrite history with +[certain filters][git-filters-manual]. +This command uses rebase to modify history and if you want to remove certain +file from history altogether use: + +```shell +git filter-branch --tree-filter 'rm filename' HEAD +``` + +Since `git filter-branch` command might be slow on big repositories, there are +tools that can use some of Git specifics to enable faster execution of common +tasks (which is exactly what removing sensitive information file is about). +An alternative is [BFG Repo-cleaner][bfg-repo-cleaner]. Keep in mind that these +tools are faster because they do not provide a same fully feature set as `git filter-branch` +does, but focus on specific usecases. + +## Conclusion + +There are various options of undoing your work with any version control system, but +because of de-centralized nature of Git, these options are multiplied (or limited) +depending on the stage of your process. Git also enables rewriting history, but that +should be avoided as it might cause problems when multiple developers are +contributing to the same codebase. + +<!-- Identifiers, in alphabetical order --> + +[bfg-repo-cleaner]: https://rtyley.github.io/bfg-repo-cleaner/ +[git-autoclean-ref]: https://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery +[git-basics]: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository +[git-debug]: https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git +[git-distributed]: https://git-scm.com/about/distributed +[git-filters-manual]: https://git-scm.com/docs/git-filter-branch#_options +[git-official]: https://git-scm.com/ +[gitlab-ce]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#contribution-acceptance-criteria +[gitlab-flow]: https://about.gitlab.com/2014/09/29/gitlab-flow/ +[gitlab-git-tips-n-tricks]: https://about.gitlab.com/2016/12/08/git-tips-and-tricks/ diff --git a/doc/user/index.md b/doc/user/index.md index f239a15d441..01db8becc43 100644 --- a/doc/user/index.md +++ b/doc/user/index.md @@ -23,9 +23,20 @@ all the way through, from within the same platform. Please check this page for an overview on [GitLab's features](https://about.gitlab.com/features/). +### Concepts + +For an overview on concepts involved when developing code on GitLab, +read the articles on: + +- [Mastering Code Review With GitLab](https://about.gitlab.com/2017/03/17/demo-mastering-code-review-with-gitlab/). +- [GitLab Workflow, an Overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario). +- [Tutorial: It's all connected in GitLab](https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/): an overview on code collaboration with GitLab. +- [Trends in Version Control Land: Microservices](https://about.gitlab.com/2016/08/16/trends-in-version-control-land-microservices/). +- [Trends in Version Control Land: Innersourcing](https://about.gitlab.com/2016/07/07/trends-version-control-innersourcing/). + ## Use cases -GitLab is a git-based platforms that integrates a great number of essential tools for software development and deployment, and project management: +GitLab is a Git-based platform that integrates a great number of essential tools for software development and deployment, and project management: - Code hosting in repositories with version control - Track proposals for new implementations, bug reports, and feedback with a @@ -58,12 +69,6 @@ and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board. You can also [integrate](project/integrations/project_services.md) GitLab with numerous third-party applications, such as Mattermost, Microsoft Teams, HipChat, Trello, Slack, Bamboo CI, JIRA, and a lot more. -### Articles - -For a complete workflow use case please check [GitLab Workflow, an Overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/#gitlab-workflow-use-case-scenario). - -For more use cases please check our [Technical Articles](../articles/index.md). - ## Projects In GitLab, you can create [projects](project/index.md) for numerous reasons, such as, host |
