Newbe Dev Stack

Answer : For more current information, this feature has now been added to gitlab and you can transfer an existing group to become a subgroup of a different existing group. The linked issue in @Zeta 's answer was closed and this issue (https://gitlab.com/gitlab-org/gitlab-ce/issues/31885) became the primary issue on this topic. At the time of writing this, the method to change a group to a subgroup is as follows: go to the group you want to turn into a subgroup. Go to the general settings of that group. Expand "Path, transfer, remove". Under this is a "Transfer group" box where you select your desired parent group that you manage. After specifying the desired parent group, hit transfer group and it should be moved to the appropriate path. Gitlab Notes (taken from gitlab web interface): Be careful. Changing a group's parent can have unintended side effects. You can only transfer the group to a group you manage. You will still need to upda...

Answer : In 8.0+ it looks like this was moved into the project. If you open your project and go to the gear icon on the right, then "Edit Project" you can set the default branch for the project. To change default branch in GitLab: 1. Settings > General > General project settings > Expand 2. Default Branch > Change your project default branch 3. Save changes in the GitLab Enterprise Edition 12.2.0-pre you have to use following: Setting → Repository → Default Branch ( expand it) and change the default branch Here

Answer : Commit and push using this syntax: git commit -m "Sort more efficiently" -m "Closes #843" git push This will commit and close the issue. Note that unlike Github a single -m will not work. The following will appear on the issue page: References: https://docs.gitlab.com/ee/user/project/issues/automatic_issue_closing.html How to commit a change with both "message" and "description" from the command line? According to this link from gitlab, you will be able to do that with a variety of words such as "fixes" or "closes". It does not need to be in a seperate line. So you could have the following message: Fixes #20. I had to replace "foo" with "bar". And that will close issue #20.

Answer : In Gitlab, the merged status means the relevant commits have been merged and no action is needed. A closed merge request is one that has been put aside or considered irrelevant. It is therefore not merged into the code base. Therefore, you only merge MRs when you're happy with the changes and close them if you think the changes are not worthy of being integrated into the code base ever. A typical workflow would be the following: User A works on a new feature in a feature branch and pushes their work to that branch. They can open a merge request to merge their feature branch into master. User B pulls the feature branch, eventually rebasing it onto master, and runs the tests they want. If User B is happy with the changes/new feature, they can merge the MR into master (or whatever branch you merge into) The merge request will be shown as merged Of course it's better if the tests run automatically in a CI. With GitLab 12.2 (August 2019), you have n...

Answer : It's not a perfect solution, but we ended up creating a cleanup job at the end of our .gitlab-ci.yaml file that deletes the cache directory from the filesystem. This way, each pipeline gets its own unique cache, without cluttering up the file system over time. cleanup_job: stage: cleanup script: - echo "Cleaning up" - rm -rf "%CACHE_PATH%/%CI_PIPELINE_ID%" when: always where CACHE_PATH: "C:/gitlab-runner/cache/group/project/repo/"