GitLab: Unterschied zwischen den Versionen

aus www.kruedewagen.de, Homepage von Ralf und Judith Krüdewagen (Kruedewagen)
Zur Navigation springen Zur Suche springen
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 29: Zeile 29:
*Web IDE
*Web IDE
**[https://www.heise.de/news/Gitpod-bietet-native-IDE-Integration-in-GitLab-4923817.html mit Gitpod]
**[https://www.heise.de/news/Gitpod-bietet-native-IDE-Integration-in-GitLab-4923817.html mit Gitpod]
==== Planning ====
*Issues (tickets) can only be created on project level. Issue are passed from bottom to down (project -> subgroup -> group). The higher the level, the more issues are gathered and shown in issue boards.
*Epics can only be created on subgroup and group level. Epics are passed from bottom to down (subgroup -> group). The higher the level, the more epics are gathered and shown in epic list/board and roadmaps.
*Roadmaps are based on epics (after dates are given). Roadmaps are passed and enriched from bottom to down (subgroup -> group).
*Permissions (members) are inherited and passed from top to bottom (group -> subgroup -> project). A permission granted on group level cannot be removed on subgroup or project level. Therefore, if we need to split permissions (e.g. for product and customer train), subgroups are needed.
*Each group can contain multiple subgroups and each subgroup can contain multiple projects.
*Group, subgroup and project names can be changed easily without impact on references. But paths (in URL) shall remain stable in order to keep references (merge requests, commits, links) valid. Therefore, paths shall be generic (e.g. team1, team2, ...) and short.


== Access to repositories ==
== Access to repositories ==
Zeile 224: Zeile 238:
*https://docs.gitlab.com/ce/operations/incident_management/
*https://docs.gitlab.com/ce/operations/incident_management/
*https://docs.gitlab.com/ce/operations/incident_management/generic_alerts.html
*https://docs.gitlab.com/ce/operations/incident_management/generic_alerts.html
*[https://about.gitlab.com/blog/2021/11/30/gitlab-incident-management/ Downtime happens, but GitLab Incident Management can help]


*Alerts werden per Schnittstelle erzeugt
*Alerts werden per Schnittstelle erzeugt
Zeile 277: Zeile 292:
*Logs
*Logs
  gitlab-ctl tail gitlab-pages
  gitlab-ctl tail gitlab-pages
== GitLab Wiki ==
=== Move / Migrate / Import a GitLab wiki ===
* https://stackoverflow.com/questions/54401112/gitlab-wiki-how-to-import-wiki-when-importing-a-repository
* If you have a mix of master/main: https://www.git-tower.com/learn/git/faq/git-rename-master-to-main
* Delete Wiki: https://stackoverflow.com/questions/4922104/is-it-possible-to-completely-empty-a-remote-git-repository


== Mattermost ==
== Mattermost ==
Zeile 300: Zeile 322:
*[https://about.gitlab.com/blog/2021/02/18/improve-your-gitlab-productivity-with-these-10-tips/ 10 tips to make you a productive GitLab user] (quick actions)
*[https://about.gitlab.com/blog/2021/02/18/improve-your-gitlab-productivity-with-these-10-tips/ 10 tips to make you a productive GitLab user] (quick actions)
*[https://about.gitlab.com/blog/2021/05/20/vscode-workflows-for-working-with-gitlab/ Visual Studio code editor: Eight tips for using GitLab VS Code]
*[https://about.gitlab.com/blog/2021/05/20/vscode-workflows-for-working-with-gitlab/ Visual Studio code editor: Eight tips for using GitLab VS Code]
*[https://about.gitlab.com/blog/2021/11/17/vscode-workflow-new-features/ Four new tools for your Visual Studio Code and GitLab tool belt]
*[https://www.heise.de/ratgeber/Einstieg-in-Git-Eigenen-Gitlab-Server-mit-Docker-aufsetzen-6050420.html Einstieg in Git: Eigenen Gitlab-Server mit Docker aufsetzen | heise online]
*[https://www.heise.de/ratgeber/Einstieg-in-Git-Eigenen-Gitlab-Server-mit-Docker-aufsetzen-6050420.html Einstieg in Git: Eigenen Gitlab-Server mit Docker aufsetzen | heise online]
*[https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks/ Top ten GitLab hacks for all stages of the DevOps Platform]


== Tools ==
== Tools ==
Zeile 313: Zeile 337:
**Sendet HTTP Request zu einem Server, auch mit Parameter/Value Variablen von simulierten Formularen
**Sendet HTTP Request zu einem Server, auch mit Parameter/Value Variablen von simulierten Formularen
**Siehe "GitLab Cookbook" S.121 - Managing your projects via the API.
**Siehe "GitLab Cookbook" S.121 - Managing your projects via the API.
== Shortkeys ==
*"." öffnet Web IDE im jeweiligen Kontext


== Weblinks ==
== Weblinks ==
Zeile 321: Zeile 348:
*[https://www.gitlab.com/gitlab-ce/ GitLab Community Edition]
*[https://www.gitlab.com/gitlab-ce/ GitLab Community Edition]
*[http://doc.gitlab.com/ce/ GitLab Community Edition Documentation]
*[http://doc.gitlab.com/ce/ GitLab Community Edition Documentation]
*[https://about.gitlab.com/upcoming-releases/ GitLab upcoming releases | GitLab]
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Installation]
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Installation]
*[http://doc.gitlab.com/ce/update/README.html GitLab Community Edition Update]
*[http://doc.gitlab.com/ce/update/README.html GitLab Community Edition Update]
Zeile 330: Zeile 358:
*[https://about.gitlab.com/handbook/product/product-principles GitLab Product Principles]
*[https://about.gitlab.com/handbook/product/product-principles GitLab Product Principles]
*[https://about.gitlab.com/community/gitlab-first-look/ GitLab First Look] - Research program for invites to usability tests, user interviews, surveys, etc.
*[https://about.gitlab.com/community/gitlab-first-look/ GitLab First Look] - Research program for invites to usability tests, user interviews, surveys, etc.
Communities:
* [https://stackoverflow.com/collectives/gitlab GitLab Collectives Stackoverflow], see [https://about.gitlab.com/blog/2021/11/08/join-the-new-gitlab-collective-on-stack-overflow/ Join the new GitLab Collective on Stack Overflow!]:


Additional components:
Additional components:
Zeile 378: Zeile 409:
*https://entwickler.de/online/agile/gitlab-serverless-angekuendigt-natives-faas-fuer-gitlab-579871325.html
*https://entwickler.de/online/agile/gitlab-serverless-angekuendigt-natives-faas-fuer-gitlab-579871325.html


Cloud:
Cloud / GitOps:
*[https://about.gitlab.com/blog/2019/11/18/gitops-prt-3/ How to deploy to any cloud using GitLab for GitOps]
*[https://about.gitlab.com/blog/2019/11/18/gitops-prt-3/ How to deploy to any cloud using GitLab for GitOps]
*[https://about.gitlab.com/blog/2021/12/02/gitops-with-gitlab-secrets-management/ GitOps with GitLab: How to tackle secrets management]


Release Strategy:
Release Strategy:
Zeile 394: Zeile 426:
Cloud-Deployment:
Cloud-Deployment:
*[https://about.gitlab.com/blog/2020/12/15/deploy-aws/ How to deploy to AWS with GitLab]
*[https://about.gitlab.com/blog/2020/12/15/deploy-aws/ How to deploy to AWS with GitLab]
Automation:
*[https://about.gitlab.com/blog/2021/11/16/engineering-managers-automate-their-jobs/ How GitLab automates engineering management | GitLab]


== See also ==
== See also ==

Aktuelle Version vom 4. Dezember 2021, 10:11 Uhr

This page describes GitLab, which is a software for Git repository management and software development that can run on your own server. GitLab also offers a hosted online service at https://gitlab.com.


Overview

GitLab is Open Source and offers Git repository management, code reviews, issue tracking, activity feeds and wikis.

Features

Major GitLab features are depicted in this article on techdo.me.

Some highlights:

  • User management.
  • SSH key management for accessing a repo via SSH and mapping to GUI user.
  • Repository/project permissions (private, protected or public). Users and groups.
  • View commits.
  • Comments.
  • Issue tracking.
  • Markdown support.
  • Branches and tags can be created in GUI.
  • Merge requests. Code review.
  • New files can be created and in the GUI.
  • Files can be edited in the GUI.
  • A wiki per project (in separate Git repo).
  • Notifications.
  • Visualization of commits, branches, etc.


Planning

  • Issues (tickets) can only be created on project level. Issue are passed from bottom to down (project -> subgroup -> group). The higher the level, the more issues are gathered and shown in issue boards.
  • Epics can only be created on subgroup and group level. Epics are passed from bottom to down (subgroup -> group). The higher the level, the more epics are gathered and shown in epic list/board and roadmaps.
  • Roadmaps are based on epics (after dates are given). Roadmaps are passed and enriched from bottom to down (subgroup -> group).
  • Permissions (members) are inherited and passed from top to bottom (group -> subgroup -> project). A permission granted on group level cannot be removed on subgroup or project level. Therefore, if we need to split permissions (e.g. for product and customer train), subgroups are needed.
  • Each group can contain multiple subgroups and each subgroup can contain multiple projects.
  • Group, subgroup and project names can be changed easily without impact on references. But paths (in URL) shall remain stable in order to keep references (merge requests, commits, links) valid. Therefore, paths shall be generic (e.g. team1, team2, ...) and short.

Access to repositories

The GitLab GUI always shows the links you need to use for accessing (cloning) the Git repositories either via HTTP or SSH.

Example URLs for project/repository:

HTTP access:

http://gitlab.example.com/group1/project1.git

SSH access on port 22:

git@gitlab.example.com/group1/project1.git
Note: The repo must be addressed with a absolute path (do not use ":" between hostname and pathname)

The corresponding clone commands are:

git clone http://gitlab.example.com/group1/project1.git
git clone ssh://git@gitlab.example.com/group1/project1.git

Notes:

  • For HTTP you need to authenticate with your GitLab user credentials, if it's not a public repo.
  • It's recommended using SSH for accessing the repositories with a Git client.
  • The SSH connect must go directly to the host GitLab has been installed on (no proxy in between).
  • For SSH you need to always login as user git. The user mapping will be made via your SSH key(s).
  • For SSH you need to authenticate with a SSH private key matching the public key you need to register in your GitLab user profile.
  • The SSH keys must be unique. You can't add a public key to multiple user profiles. The keys are added to ~git/.ssh/authorized_keys.
  • For SSH you need to take care using the correct SSH key, e.g. just add following to ~/.ssh/config:
Host gitlab.example.com
IdentityFile ~/.ssh/id_rsa_emptypass
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
  • For SSH you can check the general SSH access and authentication by just connecting to the server with a native SSH client. In addition, your GitLab user mapping will be responded by the server as e.g. Welcome to GitLab, Peter Pan!. A successful connect (using SSH port forwarding) looks like:
> ssh git@gitlab.example.com
X11 forwarding request failed on channel 0
PTY allocation request failed on channel 0
Welcome to GitLab, Peter Pan!
Connection to gitlab.example.com closed.

Operations

See Operations for info about installing and maintaining GitLab.

Docker

See hub.docker.com for running GitLab as Docker container.

Creating the container:

docker run --detach \
    --hostname gitlab.example.com \
    --publish 9443:9443 --publish 9080:9080 --publish 9022:22 \
    --name gitlab \
    --restart always \
    --volume /srv/gitlab/config:/etc/gitlab \
    --volume /srv/gitlab/logs:/var/log/gitlab \
    --volume /srv/gitlab/data:/var/opt/gitlab \
    gitlab/gitlab-ce:latest

GitLab configuration gitlab.rb:

external_url 'https://gitlab.example.com:9443'

nginx['ssl_certificate']= "/etc/gitlab/ssl/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/privkey.pem"

gitlab_rails['gitlab_shell_ssh_port'] = 9022

gitlab_rails['gitlab_email_from'] = 'gitlab@example.com'
gitlab_rails['gitlab_email_display_name'] = 'GitLab example.com'
gitlab_rails['gitlab_email_reply_to'] = 'gitlab@example.com'

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "mail.example.com"
gitlab_rails['smtp_port'] = 587
gitlab_rails['smtp_user_name'] = "user"
gitlab_rails['smtp_password'] = "pass"
gitlab_rails['smtp_domain'] = "mail.example.com"
gitlab_rails['smtp_authentication'] = "plain"
gitlab_rails['smtp_enable_starttls_auto'] = true

Notes about running GitLab on a Docker host with Port 80, 443 and 22 already occupied:

  • GitLab must be configured to set the external ports like 9443 and/or 9080. Once you set "external_url 'https://gitlab.example.com:9443'", nginx will listen on port 9443.
  • Setting the SSH port
gitlab_rails['gitlab_shell_ssh_port'] = 9022
does only work when the port forwarding from Docker is e.g. 9022->22. 9022->9022 did not work for me.
  • All these HTTP/HTTPS and SSH configured are used as ports in the GitLab user interface, e.g. in the clone URL.
  • You can/should create virtual webservers on the Docker host serving port 443 and 80 and redirecting both the the external GitLab URL.
  • For TLS with Let's Encrypt see TLS.

Update:

docker stop gitlab
docker rm gitlab
docker pull gitlab/gitlab-ce:latest
docker run ...

Troubleshooting:

docker logs gitlab
docker exec -it gitlab bash

Ports:

Weblinks:

TLS


Help

The GitLab GUI has an excellent online help available at

http://gitlab.example.com/help

Agile Project/Product Management

Issues

# Details

# Customer information
* Client reported the bug:

# Workflow

Please mark the checks if the corresponding step is __finished__.

- [ ] Bug can be reproduced :frame_photo:
- [ ] Shipment :cruise_ship:
    - [ ] Yes, the feature can be shipped automatically (continuous delivery)
    - [ ] No, we need to align date of shipment 
- [ ] Approved :vertical_traffic_light:

## Additional information
* Effort Estimation (in PT): _please add estimated duration using a [quick action](https://gitlab.kruedewagen.de:9443/help/user/project/quick_actions)_
* Is a date of shipment communicated to the client (yes|no)?
  - If yes, which date:

/label ~"bug"
#xxx
https://gitlab.com/<username>/<projectname>/issues/<xxx>

Issue Boards

Issue boards are controlled by labels. Board can be created by project/repo and also on group level.

A feature board respective product backlog with a workflow for requirement engineering could look like:

  • backlog
  • new requirement
  • business analysis
  • technical analysis
  • ready for development
  • in progress
  • in qa
  • ready for production
  • on production
  • closed

This feature boards looks like following:

Feature Board Part 1
Feature Board Part 2

EPICs

User Story

See also

Operations

Alerts und Incidents

  • Alerts werden per Schnittstelle erzeugt
  • Beispiel
TIMESTAMP=$(date +%Y-%m-%dT%H:%M:%S%z)
FINGERPRINT=$(date +%s)
curl --request POST \
  --data '{"title": "Test Alert", "description": "Short description of the alert", "start_time": "'$TIMESTAMP'", "service": "My little service", "monitoring_tool": "Icinga", "hosts": "server", "severity": "medium", "fingerprint": "'$FINGERPRINT'"}' \
  --header "Authorization: Bearer <key>" \
  --header "Content-Type: application/json" \
  https://gitlab.example.com/group1/project1/alerts/notify.json
Achtung: "fingerprint" muss unique sein, sonst wird kein neuer Alert/Issue erzeugt (z.B. als UUID um wiederkehrende Alert erkennen, Anzahl "Events" wird sonst hochgezählt). "key" wird aus den GitLab-Einstellungen für den Aufruf der Schnittstelle übernommen.
  • Incidents können automatisch aus Alerts erzeugt werden (Einstellungen, Template möglich) oder manuell aus einem Alert in der GitLab GUI erstellt werden.
  • Incidents sind eine bestimmte Art von Issues mit anderen Detail-Infos (z.B. Severity).
  • Incidents haben einen Tag "incident"

Docker Registry

  • Aufräumen:
gitlab-ctl registry-garbage-collect

GitLab Pages

In combination with other tools (e.g. markdown converter, CMS):


Troubleshooting

gitlab-ctl tail gitlab-pages

GitLab Wiki

Move / Migrate / Import a GitLab wiki

Mattermost

Literature and Tutorials

Tools

  • RequestBin
    • Testen von HTTP Requests, z.B. für den Empfang von Webhooks bei Git/GitLab.
    • Siehe "GitLab Cookbook" S.113 - Using webhooks.
    • RequestBin gives you a URL that will collect requests made to it and let you inspect them in a human-friendly way. Use RequestBin to see what your HTTP client is sending or to inspect and debug webhook requests.
  • Postman
    • REST Client, Testen von APIs
    • Chrome Browser Extension
    • Sendet HTTP Request zu einem Server, auch mit Parameter/Value Variablen von simulierten Formularen
    • Siehe "GitLab Cookbook" S.121 - Managing your projects via the API.

Shortkeys

  • "." öffnet Web IDE im jeweiligen Kontext

Weblinks

GitLab official sites:

Communities:

Additional components:

Webcasts:

Other resources:

Using under openSUSE:

Markdown:

Continuous Integration (CI/CD):

Serverless / FaaS:

Cloud / GitOps:

Release Strategy:

Agile Software Development:

Planning:

Cloud-Deployment:

Automation:

See also