Gitlab commit messages - gitlab

We're using Gitlab for source control, and MantisBT for issue tracking (boss's orders!)
Now we want to implement some kind of regex in the Gitlab commit messages, when a commit contains 'Mantis#1' that it automaticly generates a URL to http://mantis.local/view.php?id=1
Is this possible in Gitlab, (without having to write in Ruby?), and if so, how ?

It's impossible without writing code. As variant you can try change config file:
Here described logic for Internal issue trackers. Here described rules for internal issue trackers. You can try configure your own tracker support.
As example (I don't know which urls in your issue tracker)
issues_tracker:
mantisbt:
title: "MantisBT"
project_url: "http://mantis.local/projects/:issues_tracker_id"
issues_url: "http://mantis.local/view.php?id=:id"
new_issue_url: "http://mantis.local/projects/:issues_tracker_id/issues/new"

Related

GitLab API: Get branch associated with issue

In a GitLab issue, you can associate a branch with an issue, and in the issue there will be the line
#whoever created the branch branchname to address this issue.
Is there a way of getting that branch using the issues API? I'm trying to set up an automation script that will merge all branches associated with issues that have a certain label into the prod branch, then push the result as a development brnach so I can deploy that to a dev environment. I don't want to use merge requests as they will be used when the dev work is complete and ready to be merged for deployment to production.
Unfortunately, there currently is no official API to fetch an issue's related branches.
Some possible ways you can work around this:
Use the notes API
When a user uses the issue interface to create the branch, you will see a system message, like you mention. This message will be present in the notes API for the issue.
Example using the python-gitlab library:
import re
...
branch_note_pattern = '^created branch \[\`(.*)\`\].*to address this issue'
issue = project.issues.get(ISSUE_NUMBER)
all_notes = list(issue.notes.list(as_list=False))
system_notes = [note for note in all_notes if note.system]
related_branches = []
for note in system_notes:
match = re.match(branch_note_pattern, note.body):
if match:
branch = match.groups()[0]
related_branches.append(branch)
print('BRANCHES RELATED TO ISSUE', ISSUE_NUMBER)
for branch_name in related_branches:
print(branch_name)
However, it is possible to have a related branch without that note appearing because the related branches is just based on naming convention. So, if someone just creates a branch with named like <issue_number>-some-branch-name then it will show up as a related branch, but there will not be a system message in the API.
So, if you rely on the notes API, you may miss related branches created manually.
Use the unofficial frontend API
The issues controller only returns related branches for the purposes of the frontend to render as HTML.
If you request /<:project_url>/-/issues/<:issue_number>/related_branches?format=json you will get a JSON response containing the HTML for the frontend to insert in the issue view. You can parse this HTML to get the related branches.
This will reliably fetch the same related branches you'll see in the UI, but is more work to implement, and is fragile because the API is not guaranteed to be stable between versions of GitLab.

How can I associate an Routing Rule to a proxy repository on Nexus OSS via Groovy?

I’ve been able to create, using the Nexus groovy scripts, more specifically associating a Routing Rule to and existing repository.
It’s pretty easy to create one; such code evaluated fine from Groovy:
RoutingRule routingRule = new RoutingRule("com.company only API", "only com.company content", RoutingMode.BLOCK, ["^(?!/com/company)/.*\$"])
The part I could not figure out was how to persist this rule and attach it to an existing repository.
I tried with: Configuration.setRoutingRuleId(EntityHelper.id(ruleName)) without success.
Anyone know-how is the correct configuration to associate a proxy repository to a routing rule?
Nexus OSS version: 3.19.1-01
Edit:
I solved my problem by updating my version of Nexus to OSS 3.21.1-01 and start using the API that now they have RoutingRules methods.
Not sure if you've found an answer here given it's already 2 months old. I was also having this problem and took me long to figure this out so for anyone looking:
def rule = routingRuleStore.getByName('RULENAME')
config.routingRuleId = org.sonatype.nexus.common.entity.EntityHelper.id(rule)
Then you can save/update with
repositoryManager.create(config)
repositoryManager.update(config)

Getting whole repository structure from GitHub API using one request

Is it possible to somehow get information about whole repository using one request to github api or we have to recursively asking API for specific level?
According to this request: https://api.github.com/repos/microsoft/terminal/contents?ref=master
we are only getting one level.
You can get the tree recursively using :
/repos/:owner/:repo/git/trees/:tree_sha?recursive=1
In your case it would be :
https://api.github.com/repos/microsoft/terminal/git/trees/master?recursive=true
You can make a request to here to see details about your branch:
https://api.github.com/repos/{owner}/{repo}/branches/{default_branch}
In the response you will see "commit" field and inside of it there is "sha". Take that one put it in this request:
https://api.github.com/repos/{owner}/{repo}/git/trees/YOUR_SHA_GOES_HERE?recursive=1
You will receive every file under your repo like this.
Cheers!

Is there a command or a "git log" option to retrieve comments/discussion logged for a merge request?

We have a GITlab(8.14) running for collaboration within the company.
I am working on a python script to collect information about merge requests being raised by developers across projects. I can very easily isolate the merge requests using 'git log'
git log --merges
However, I haven't been able to locate the correct command or option to retrieve all the discussion/comments taking place in the Merge Request.
Solution 1: use Gitlab Log System
Have you thought to use the Gitlab Log System instead of using a Git command?
It contains information about all performed requests.... Also you can see all
SQL request that have been performed and how much time it took.
Please take a look here https://docs.gitlab.com/ee/administration/logs.html
So in your Python script of collecting information, you can use queries like that:
SELECT <things> FROM "merge_requests" WHERE <condition>
Solution 2: use Gitlab API
Another way is to directly request Gitlab API to get a list of all notes for a single merge request.
Notes are comments on snippets, issues or merge requests.
like this:
GET /projects/:id/merge_requests/:merge_request_id/notes
The complete API reference for merge request notes is available here.
Does this help you?

Construct GitLab URL without slug

Is there any way to build a GitLab URL for a milestone or project based on its id property instead of the slug?
Context:
I have an app that I use as a GitLab web hook, and from its front end would like to link back to GitLab. I'm keeping the project and milestone ids, as they are unique, but can't find a way to link back to them. Ideally something like: http://gitlab.example.com/project/83/milestone/113 or even http://gitlab.example.com/milestone/113 would work for me (even if they do a redirect).
Examining rake routes and config/routes.rb tells me that such routes do not exist.
The only options I can see are:
store just the slugs which are also unique. Your request and memory usage will be slightly larger, but it's worth it.
make an extra API request to get the slugs. This requires 2 requests, so it is worse than having a larger request.
For new routes of form /something to be created in gitlab, something needs to be blacklisted at https://github.com/gitlabhq/gitlabhq/blob/199029b842de7c9d52b5c95bdc1cc897da8e5560/lib/gitlab/blacklist.rb, and interestingly projects is already blacklisted, but it is currently only used for project creation.
milestones however is not blacklisted: so a user could be called milestiones and that would generate ambiguity.
I would also take a close look at how GitHub organizes its API and paths, as it is likely to be optimal: is ID web access possible in GitHub?

Resources