12 Notes
+ Traefik, Swarmpit, Gitlab CE (Oct. 18, 2021, 5:32 p.m.)

1- Create a directory to hold all gitlab setup dependencies: sudo su - mkdir -p ~/services/gitlab cd ~/services/gitlab mkdir -p data/config data/logs data/data 2- Create a docker-compose file and paste the following contents in it: vim docker-compose.yml version: '3' services: gitlab: image: gitlab/gitlab-ce:latest environment: GITLAB_OMNIBUS_CONFIG: | external_url '' nginx['listen_https'] = false nginx['listen_port'] = 80 volumes: - ./data/config:/etc/gitlab - ./data/logs:/var/log/gitlab - ./data/data:/var/opt/gitlab networks: - traefik-public ports: - 2222:22 deploy: labels: - traefik.enable=true - - traefik.constraint-label=traefik-public - traefik.http.routers.gitlab-http.rule=Host(``) - traefik.http.routers.gitlab-http.entrypoints=http - traefik.http.routers.gitlab-http.middlewares=https-redirect - traefik.http.routers.gitlab-https.rule=Host(``) - traefik.http.routers.gitlab-https.entrypoints=https - traefik.http.routers.gitlab-https.tls=true - traefik.http.routers.gitlab-https.tls.certresolver=le - networks: traefik-public: external: true 4- Deploy the gitlab stack: docker stack deploy -c docker-compose.yml gitlab View the logs and wait for them to finish setup: docker service logs gitlab_gitlab -f 5- Open the address in the URL and log in: username: root password: (It's in the file ~/services/gitlab/data/config/initial_root_password) --------------------------------------------------------------------------------- - Log in with root account - Change the password - Set an optional email address - Create a new user - Set a password for the user to log in - Log in with the new user account - Set an SSH key - Test if it works: ssh -p 2222 -T - It should return: Welcome to GitLab, @mohsen! ---------------------------------------------------------------------------------

+ Gitlab CE with Docker Compose (Sept. 20, 2020, 9:37 a.m.)

version: "3.8" services: gitlab: image: 'gitlab/gitlab-ce:latest' container_name: gitlab restart: always hostname: '' environment: GITLAB_OMNIBUS_CONFIG: | external_url '' ports: - '80:80' - '443:443' - '4022:22' volumes: - '/srv/gitlab/config:/etc/gitlab' - '/srv/gitlab/logs:/var/log/gitlab' - '/srv/gitlab/data:/var/opt/gitlab' ------------------------------------------------------------------------ username: root password: (It's in the file /srv/gitlab/config/initial_root_password) ------------------------------------------------------------------------

+ Gitlab Flow (Oct. 8, 2018, 2:38 p.m.)

In git you add files from the working copy to the staging area. After that you commit them to the local repo. The third step is pushing to a shared remote repository. After getting used to these three steps the branching model becomes the challenge. Since many organizations new to git have no conventions how to work with it, it can quickly become a mess. The biggest problem they run into is that many long running branches that each contain part of the changes are around. People have a hard time figuring out which branch they should develop on or deploy to production. Frequently the reaction to this problem is to adopt a standardized pattern such as git flow and GitHub flow. We think there is still room for improvement and will detail a set of practices we call GitLab flow. Git flow and its problems: Git flow was one of the first proposals to use git branches and it has gotten a lot of attention. It advocates a master branch and a separate develop branch as well as supporting branches for features, releases and hotfixes. The development happens on the develop branch, moves to a release branch and is finally merged into the master branch. Git flow is a well defined standard but its complexity introduces two problems. The first problem is that developers must use the develop branch and not master, master is reserved for code that is released to production. It is a convention to call your default branch master and to mostly branch from and merge to this. Since most tools automatically make the master branch the default one and display that one by default it is annoying to have to switch to another one. The second problem of git flow is the complexity introduced by the hotfix and release branches. These branches can be a good idea for some organizations but are overkill for the vast majority of them. Nowadays most organizations practice continuous delivery which means that your default branch can be deployed. This means that hotfix and release branches can be prevented including all the ceremony they introduce. An example of this ceremony is the merging back of release branches. Though specialized tools do exist to solve this, they require documentation and add complexity. Frequently developers make a mistake and for example changes are only merged into master and not into the develop branch. The root cause of these errors is that git flow is too complex for most of the use cases. And doing releases doesn't automatically mean also doing hotfixes. GitHub flow as a simpler alternative: In reaction to git flow a simpler alternative was detailed, GitHub flow. This flow has only feature branches and a master branch. This is very simple and clean, many organizations have adopted it with great success. Atlassian recommends a similar strategy although they rebase feature branches. Merging everything into the master branch and deploying often means you minimize the amount of code in 'inventory' which is in line with the lean and continuous delivery best practices. But this flow still leaves a lot of questions unanswered regarding deployments, environments, releases and integrations with issues. With GitLab flow we offer additional guidance for these questions. Production branch with GitLab flow: GitHub flow does assume you are able to deploy to production every time you merge a feature branch. This is possible for e.g. SaaS applications, but there are many cases where this is not possible. One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass App Store validation. Another example is when you have deployment windows (workdays from 10am to 4pm when the operations team is at full capacity) but you also merge code at other times. In these cases you can make a production branch that reflects the deployed code. You can deploy a new version by merging in master to the production branch. If you need to know what code is in production you can just checkout the production branch to see. The approximate time of deployment is easily visible as the merge commit in the version control system. This time is pretty accurate if you automatically deploy your production branch. If you need a more exact time you can have your deployment script create a tag on each deployment. This flow prevents the overhead of releasing, tagging and merging that is common to git flow. Environment branches with GitLab flow: It might be a good idea to have an environment that is automatically updated to the master branch. Only in this case, the name of this environment might differ from the branch name. Suppose you have a staging environment, a pre-production environment and a production environment. In this case the master branch is deployed on staging. When someone wants to deploy to pre-production they create a merge request from the master branch to the pre-production branch. And going live with code happens by merging the pre-production branch into the production branch. This workflow where commits only flow downstream ensures that everything has been tested on all environments. If you need to cherry-pick a commit with a hotfix it is common to develop it on a feature branch and merge it into master with a merge request, do not delete the feature branch. If master is good to go (it should be if you are practicing continuous delivery) you then merge it to the other branches. If this is not possible because more manual testing is required you can send merge requests from the feature branch to the downstream branches. Release branches with GitLab flow: Only in case you need to release software to the outside world you need to work with release branches. In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.). The stable branch uses master as a starting point and is created as late as possible. By branching as late as possible you minimize the time you have to apply bug fixes to multiple branches. After a release branch is announced, only serious bug fixes are included in the release branch. If possible these bug fixes are first merged into master and then cherry-picked into the release branch. This way you can't forget to cherry-pick them into master and encounter the same bug on subsequent releases. This is called an 'upstream first' policy that is also practiced by Google and Red Hat. Every time a bug-fix is included in a release branch the patch version is raised (to comply with Semantic Versioning) by setting a new tag. Some projects also have a stable branch that points to the same commit as the latest released branch. In this flow it is not common to have a production branch (or git flow master branch). Merge/pull requests with GitLab flow: Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and others choose the name merge request since that is the final action that is requested of the assignee. In this article we'll refer to them as merge requests. If you work on a feature branch for more than a few hours it is good to share the intermediate result with the rest of the team. This can be done by creating a merge request without assigning it to anyone, instead you mention people in the description or a comment (/cc @mark @susan). This means it is not ready to be merged but feedback is welcome. Your team members can comment on the merge request in general or on specific lines with line comments. The merge requests serves as a code review tool and no separate tools such as Gerrit and reviewboard should be needed. If the review reveals shortcomings anyone can commit and push a fix. Commonly the person to do this is the creator of the merge/pull request. The diff in the merge/pull requests automatically updates when new commits are pushed on the branch. When you feel comfortable with it to be merged you assign it to the person that knows most about the codebase you are changing and mention any other people you would like feedback from. There is room for more feedback and after the assigned person feels comfortable with the result the branch is merged. If the assigned person does not feel comfortable they can close the merge request without merging. In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers can't modify these protected branches. So if you want to merge it into a protected branch you assign it to someone with maintainer authorizations. Issue tracking with GitLab flow: GitLab flow is a way to make the relation between the code and the issue tracker more transparent. Any significant change to the code should start with an issue where the goal is described. Having a reason for every code change is important to inform everyone on the team and to help people keep the scope of a feature branch small. In GitLab each change to the codebase starts with an issue in the issue tracking system. If there is no issue yet it should be created first provided there is significant work involved (more than 1 hour). For many organizations this will be natural since the issue will have to be estimated for the sprint. Issue titles should describe the desired state of the system, e.g. "As an administrator I want to remove users without receiving an error" instead of "Admin can't remove users.". When you are ready to code you start a branch for the issue from the master branch. The name of this branch should start with the issue number, for example '15-require-a-password-to-change-it'. When you are done or want to discuss the code you open a merge request. This is an online place to discuss the change and review the code. Opening a merge request is a manual action since you do not always want to merge a new branch you push, it could be a long-running environment or release branch. If you open the merge request but do not assign it to anyone it is a 'Work In Progress' merge request. These are used to discuss the proposed implementation but are not ready for inclusion in the master branch yet. Pro tip: Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it's ready. When the author thinks the code is ready the merge request is assigned to reviewer. The reviewer presses the merge button when they think the code is ready for inclusion in the master branch. In this case the code is merged and a merge commit is generated that makes this event easily visible later on. Merge requests always create a merge commit even when the commit could be added without one. This merge strategy is called 'no fast-forward' in git. After the merge the feature branch is deleted since it is no longer needed, in GitLab this deletion is an option when merging. Suppose that a branch is merged but a problem occurs and the issue is reopened. In this case it is no problem to reuse the same branch name since it was deleted when the branch was merged. At any time there is at most one branch for every issue. It is possible that one feature branch solves more than one issue.

+ Uninstall (Oct. 23, 2018, 3:55 p.m.)

1- sudo gitlab-ctl uninstall 2- sudo gitlab-ctl cleanse 3- sudo gitlab-ctl remove-accounts 4- sudo dpkg -P gitlab-ce 5- Delete these directories: rm -r /opt/gitlab/ rm -r /var/opt/gitlab rm -r /etc/gitlab rm -r /var/log/gitlab

+ Docker (Dec. 15, 2018, 2:34 p.m.)

docker pull gitlab/gitlab-ce:latest ----------------------------------------------------------- docker run -d --hostname -p 30443:443 -p 3080:80 -p 3022:22 --name gitlab --restart always -v /var/docker_data/gitlab/config:/etc/gitlab -v /var/docker_data/gitlab/logs:/var/log/gitlab -v /var/docker_data/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest -----------------------------------------------------------

+ Markdown Cheatsheet (March 10, 2018, 6:44 p.m.)

+ Runner - .gitlab-ci.yml sample (Feb. 14, 2018, 10:08 a.m.)

update_docs: script: - mkdocs build - ssh-keyscan -H >> ~/.ssh/known_hosts - scp -rC site/* - ssh "/etc/init.d/nginx restart"

+ Send Notifications to Email (April 12, 2017, 1:33 p.m.) ----------------------------------------------------------------- To test the mail server: 1- sudo gitlab-rails console production ----------------------------------------------------------------- 2- Look at the ActionMailer delivery_method: ActionMailer::Base.delivery_method ----------------------------------------------------------------- 3- Check the mail settings: If it's configured with smtp: ActionMailer::Base.smtp_settings If it is sendmail: ActionMailer::Base.sendmail_settings You may need to check your local mail logs (e.g. /var/log/mail.log) for more details. ----------------------------------------------------------------- 4- Send a test message via the console. Notify.test_email('', 'Hello World', 'This is a test message').deliver_now In case the email is not sent (after checking your mail), you can see the reason/error in: tail -f /var/log/mail.log ----------------------------------------------------------------- 5- If you needed to change any configs, refer to this file: vim /var/opt/gitlab/gitlab-rails/etc/gitlab.yml OR depending on your gitlab version, maybe this one: /etc/gitlab/gitlab.rb And after any change to it: gitlab-ctl reconfigure ----------------------------------------------------------------- For fixing some problems I had to replace "sendmail" with the default "postfix". apt install sendmail (will remove postfix and install sendmail) In /etc/hosts I had to put the required domain names to fix the error " Sender address rejected: Domain not found". -----------------------------------------------------------------

+ Deleting a runner (March 8, 2017, 6:08 p.m.)

gitlab-runner unregister --name runner-0 For deleting all: gitlab-runner verify --delete

+ Install Gitlab Runner (Feb. 25, 2017, 1:39 p.m.)

GitLab Runner is an application that processes builds. It can be deployed separately and work with GitLab CI through an API. In order to run tests, you need at least one GitLab instance and one GitLab Runner. ----------------------------------------------------------- Runners: In GitLab CI, Runners run your YAML. A Runner is an isolated (virtual) machine that picks up jobs through the coordinator API of GitLab CI. A Runner can be specific to a certain project or serve any project in GitLab CI. A Runner that serves all projects is called a shared Runner. ----------------------------------------------------------- For installing on Docker, refer to the section below. 1- Add GitLab's official repository: curl -L | sudo bash 2- Install gitlab-ci-multi-runner: apt install gitlab-runner 4- Register the Runner: gitlab-runner register ----------------------------------------------------------- Install inside a Docker container: 1- Use Docker volumes to start the Runner container: docker volume create gitlab-runner-config 2- Start the Runner container using the volume we just created: docker run -d --name gitlab-runner --restart always \ -v /var/run/docker.sock:/var/run/docker.sock \ -v gitlab-runner-config:/etc/gitlab-runner \ gitlab/gitlab-runner:latest ----------------------------------------------------------- Register the Runner: docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register For registering a runner, some configurations are needed. Answer them based on your GitLab Runner page (for the URL and token). Please enter the executor: docker Please enter the Docker image: alpine:latest -----------------------------------------------------------

+ Install GitLab on server (Feb. 25, 2017, 10:46 a.m.) ----------------------------------------------------------- 1- Install and configure the necessary dependencies: sudo apt-get install curl openssh-server ca-certificates postfix 2- Add the GitLab package server and install the package: curl -sS | sudo bash sudo apt-get install gitlab-ce 3- Configure and start GitLab: sudo gitlab-ctl reconfigure 4- Browse to the hostname and login: On your first visit, you'll be redirected to a password reset screen to provide the password for the initial administrator account. Enter your desired password and you'll be redirected back to the login screen. The default account's username is "root". Provide the password you created earlier and login. After login you can change the username if you wish.

+ Install GitLab CI (Feb. 25, 2017, 10:16 a.m.)

GitLab CI is a part of GitLab, a web application with an API that stores its state in a database. It manages projects/builds and provides a nice user interface, besides all the features of GitLab. ---------------------------------------------------------------- Starting from version 8.0, GitLab Continuous Integration (CI) is fully integrated into GitLab itself and is enabled by default on all projects. ---------------------------------------------------------------- GitLab offers a continuous integration service. If you add a .gitlab-ci.yml file to the root directory of your repository, and configure your GitLab project to use a Runner, then each merge request or push, triggers your CI pipeline. ----------------------------------------------------------------