Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

New help files and associated routes

  • Loading branch information...
commit 93a3c97fa9da2228ccc521899f0e844e43742665 1 parent f9c51e3
owindsor authored
19 app/views/help/deployment_keys.html
View
@@ -0,0 +1,19 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+
+<html>
+<head>
+ <meta name="generator" content="HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
+
+ <title></title>
+</head>
+
+<body>
+ <h1>Deployment keys</h1>
+
+ <p>Gitlab has the concept of deployment keys. These are keys that are able to access the repositories but are only able to read the content, not commit back any changes. Additionally, deployment keys are not associated with users and as a matter of good practice, you should never use a key that a user has assigned to their profile as a deployment key. The rules for the deployment user will override their core behaviours. With respect to jenkins, we use a single key for jenkins based access which you are able to get out of the password manager - I have some hesitation putting it in this doc as it is out in github.</p>
+
+ <h3>Adding Deployment Keys</h3>
+
+ <p>Deployment keys are quite straight forward to add. Go to the main project view, then on the far right will be the deployment keys button, Click that and paste in the key. For Jenkins, The key name should be "Jenkins CI" that way they are simple to differentiate from any other deployment keys in the system</p>.
+</body>
+</html>
13 app/views/help/index.html.haml
View
@@ -17,10 +17,21 @@
= link_to "Permissions", help_permissions_path
%li
= link_to "Git Cheat Sheet", help_git_cheat_sheet_path
+ %li
+ = link_to "Update Remotes", help_update_remotes_path
+ %li
+ = link_to "Merging Changes", help_merging_path
%h3 Administrator Help
%ol
%li
= link_to "Getting Started - Administrators", help_getting_started_admin_path
%li
- = link_to "Applying Branch Permissions", help_branch_permissions_path
+ = link_to "Applying Branch Permissions", help_branch_permissions_path
+ %li
+ = link_to "Deployment Keys", help_deployment_keys_path
+
+%h3 Known Issues
+%ol
+ %li
+ = link_to "List of known issues", help_known_issues_path
25 app/views/help/known_issues.html
View
@@ -0,0 +1,25 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title></title>
+</head>
+<body>
+
+<h1>Known issues</h1>
+
+<p>This is not intended to be an exhaustive list, but it is intended to outline some of the things that we know are not working as expected, or have been requested as features</p>
+
+<ol>
+ <li>Alphabetical project sorting (admin and user interface) - (feature)</li>
+ <li>Commits showing in Project feeds - (bug)</li>
+ <li>User groups - (feature)</li>
+ <li>Ability to Merge changes from the interface - (feature)</li>
+ <li>Project search improvements - (feature)</li>
+ <li>API - (Feature)</li>
+ <li>Better project descriptions (Markdown or read README.md) - (Feature)</li>
+ <li>Global Repository/project access - (feature)</li>
+</ol>
+
+</body>
+</html>.
76 app/views/help/merging.html
View
@@ -0,0 +1,76 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<html>
+<head>
+<meta name="generator" content="HTML Tidy, see www.w3.org">
+<title></title>
+</head>
+<body>
+<h1>Merging Changes</h1>
+
+<p>This is a quick outline of how to merge changes. This may be
+applied to both upstream merge requests and also to and from
+feature branches. The primary thing to remember is the direction
+that you complete the merge in. In this example, we will merge a
+chance from the DEV branch to the MASTER branch;</p>
+
+<h3>For the impatient;</h3>
+
+<pre>
+ git fetch origin
+ git checkout -b dev origin/dev
+ git checkout master
+ git merge dev
+ git push origin master
+</pre>
+
+<h3>The complete explanation</h3>
+
+<p>You have a branch that you have been working on that is called
+dev. This is your feature branch that contains a set of changes.
+You want to commit it to the master branch so that people are
+able to grab it from there and work on it. This is also in
+preparation for it being moved in to the production branch once
+it has been tested and verified.</p>
+
+<strong>Step 1 - Fetch the origin source to make sure that you
+are in sync.</strong>
+
+<pre>
+ git fetch origin
+</pre>
+
+<strong>Step 2 - Checkout the dev branch, based against
+origin/dev</strong>
+
+<pre>
+ git checkout -b dev origin/dev
+</pre>
+
+<strong>Step 3 - Checkout the Master branch</strong>
+
+<pre>
+ git checkout master
+</pre>
+
+<strong>Step 4 - Merge the Dev branch in to the currently checked
+out master</strong>
+
+<p>The direction in this step is important. You are asking to
+include changes from the dev branch in to the master branch. If
+you were currently working within the dev branch and you asked to
+merge in the master branch, then you would be taking changes FROM
+Master, not adding them to it.</p>
+
+<pre>
+ git merge dev
+</pre>
+
+<strong>Step 5 - Push the changes back up to the remote server,
+to the branch Master</strong>
+
+<pre>
+ git push origin master
+</pre>
+</body>
+</html>
+
5 config/routes.rb
View
@@ -12,7 +12,10 @@
get 'help/workflow' => 'help#workflow'
get 'help/branch_permissions' => 'help#branch_permissions'
get 'help/update_remotes' => 'help#update_remotes'
-
+ get 'help/git_cheat_sheet' => 'help#git_cheat_sheet'
+ get 'help/merging' => 'help#merging'
+ get 'help/deployment_keys' => 'help#deployment_keys'
+ get 'help/known_issues' => 'help#known_issues'
namespace :admin do
resources :users do
Please sign in to comment.
Something went wrong with that request. Please try again.