In the latest(4.9) Mattermost, it provides integration with Gitlab and a Beta plugin for JIRA.
I followed the documents to finish the integration, and it works, I got notifications for the "create", "close" and "reopen" operation.
For the BUG issue, we'd like to make it "Resolved" so that our QA engineer will verify it, then it can be closed, but the "resolve" operation will not trigger any notifications neither in Gitlab nor JIRA.
I tried to use tcpdump to capture the TCP package, and it turns out that JIRA actually has sent the hook message to Mattermost. It seems to be mattermost itself who ignored those events.
Is there any configuration for such things? What can I do to meet our requirements?
BTW, I'm using the Docker preview version of Mattermost server.
Related
We upgraded our self-hosted gitlab-ce to the latest 11.11 which brings in multiple reviewer merge request approval feature. Although this needs to be explicitly enabled via gitlab-rails console.
On the machine running our gitlab instance, I ran gitlab-rails console and got to a ruby console where I put in Feature.enable(:approval_rules) and hit Enter but I get:
>> Feature.enable(:approval_rules)
Nothing known about Feature.enable(
I do not have much experience with ruby so am not sure what am doing wrong. I searched on the web but I found documentation on how to develop with Ruby's "feature flags" but not how to enable them as a end user of the application.
You can do it via the GitLab api.
POST to https://gitlab.myhost.com/api/v4/features/approval_rules with the payload
{
"value": true
}
https://docs.gitlab.com/ee/api/features.html
Additionally, I found that the new approval rules workflow was automatically enabled upon upgrading from 11.9 to 11.10, though my experience may be different. If you perform a GET to that API endpoint, you will be able to see its current status.
If it is already enabled, perhaps you may be mistaking the new approval rules implementation with the EE feature Multiple Approval Rules. I only mention due to the -ce tag in your question.
With GitLab 13.5 (October 2020), actual feature flags are available for all:
Feature Flags made available in all tiers
In GitLab 11.4, we introduced Feature Flags.
In GitLab 12.2, we introduced percent rollout and user ID Feature Flag strategies.
In GitLab 13.1, we introduced Feature Flag user lists and support for multiple Feature Flag strategies per environment.
Earlier this year, we committed to moving 18 features to our open source Core product and took the first step in delivering on this promise by making Feature Flags available in Starter in the last release.
Now we’ve officially finished moving Feature Flags to our Core offering. We’re excited about making these features available to more of the GitLab community and seeing the positive impact it’ll have on your development workflow.
See Documentation and Issue.
That includes, still with GitLab 13.5 (October 2020):
Feature Flags flexible rollout strategy
When you use the percent rollout strategy today, the stickiness, or the experience consistency, is determined only by the user ID. This can be limiting; as an example, anonymous users cannot be affected by this strategy.
We have improved this rollout strategy by enabling you to define the stickiness based on session ID, user ID, or at random (no stickiness). This gives you more control over the rollout and allows you to support stickiness for anonymous users.
See Documentation and Issue.
The feature flag API is more about creation/update/deletion.
You will have to use a feature flag strategy in order to enable/disable a feature flag.
Feature.disable(:feature_flags_new_version)
Feature.enable(:feature_flags_new_version)
See also GitLab 13.6 (November 2020)
Fire Webhook on Feature Flag change
As a developer, you can use GitLab’s webhook features for various events, such as MR events, pipeline events, job events, and deployment events. In this release, you can now use webhook events when a feature flag is toggled either on or off. This addition streamlines the process to update your CI/CD pipelines, receive Slack notifications for events, and more. A huge thanks to Sashi for a great community contribution!
See Documentation and Issue.
I have written an entire software development course, and until recently we've been using Bitbucket. I recently rewrote the course to use GitLab instead, mostly because GitLab the username isn't tied to a particular email like Bitbucket. I had heard good things. But I'm running into problems already.
The first is that merge requests (what the other hosting services call "pull requests") are not sending out notifications to approvers. We just had the lesson where I taught my students to create merge requests. I had them add me as "Reporter" to their projects. Then I had them create a merge request, and add me as an "Approver".
Yet I received no email notifying me that two student had created merge requests with me as an approver on each. I double-checked, and my global notifications are set to "Participate".
I reported this issue in a comment to a GitLab ticket, but received no response. I even filed a new official GitLab bug report; someone finally looked at it, and created another ticket for GitLab EE. So far no one has actually found the problem.
So as a workaround I went into my GitLab nofication settings and set the notification level for each student repository to "Watch" so that I (in theory) should be notified of any activity at all. Sure enough, I was notified when my students created merge requests.
Unfortunately even with a notification level of "watch", I was not notified when a student updated a merge request by making a new commitment to the branch and pushing it to GitLab.
Am I doing something wrong? Why am I not getting notifications of merge requests on which I am approver—not even when I'm watching the project? If I can't get this simple, core functionality to work I guess we'll move to Github, now that they introduced private repositories.
Role "Reporter" cannot accept/manager Merge Requests in the repository. See the whole list of permissions but basically they are:
Guest: Read only access
Reporter: Issues and comments
Developer: Push, actions to the repository
Maintainer: Admin
I did not test myself but maybe GitLab notifications check this internally. My recommendation is to protect the master branch or develop depending on your Git Workflow. Ideally only Maintainers can push or merge to protected branches after code review, so you should be assigned this role in the repos to approved things and hopefully receive the notifications. The global notification should be "Participate" and this is propagated to all your repos to avoid be overwhelmed by notifications ("Watch" notify all the activities in the repos). Developers should create feature or bugfix branches from master/develop and push always to this branch.
Suggestion
I would research some Git Workflow: Github, GitLab or GitFlow are very good examples to analyse. You can adapt the workflow to your own needs. Another MUST should be to configure GitLab CI/CD before merging into the protected branches to assure the robustness and quality of the code and teach the students good practices from the beginning.
UPDATE 2
This is happening in the CE and EE. No emails are sent when pushing new commits to Merge Requests. I tested with "Watch", "Custom", "Participate", "Developer", "Maintainer" and no emails have been sent. Actually "Custom" has an specific option for "Push to Merge Requests". However even not ideal, there is a workaround if you want to use it. Actually it also sends the diff between commits inside the email. In Settings/Integration there is an option Emails on push. You can configure there a list of emails to send the notifications. See the image below. If you want to be informed when someone push new commits to the MR another workaround is to configure the CI pipeline. You will receive an email if the pipeline fails or succeeds (this is the way we are doing). Let's wait until GitLab people answers to your GitLab ticket. If this is a NO GO issue for you and none of the workarounds work for you, I would move to GitHub Private Repositories.
Is there a way to find out who pushed a particular commit to gitlab - In the commit log (I see the author set via the git client config) , I instead want to see which gitlab user's authentication was used to PUSH that code ?
PS: There are multiple git specific questions asked and there was no solution provided in the previous questions - want to see if gitlab has some specific implementation to solve this ?
2018: I answered "no" 5 years ago, but GitLab offers audit logs of its own: As mentioned here HTTP and SSH requests are logged in different files:
HTTP: nginx/gitlab_access.log
SSH: gitlab-shell.log
However, that won't give you the SHA1(s) pushed, only the push event date and IP: you still need to cross-reference that with a commit date, to get an idea of who did push a given commit.
GitLab 14.9 (March 2022) seems to include push events (but for Premium/Ultimate editions only):
New audit events
The GitLab 14.9 release adds support for auditing the following activities:
Creating a new merge request approval rule.
Deleting a merge request approval rule.
Approving a merge request. (Supported as streaming audit events only.)
Creating, deleting, or revoking a project or group deploy token.
Failed attempts to create a project or group deploy token.
Authenticated git push or git pull commands to a private repository performed over either SSH or HTTPS (Supported as streaming audit events only.)
See Documentation and Issue.
Only commit status can be known. But person who actually pushed cannot be known.
because of the confusing nature of your question, I am only able to provide simple answers.
If what you are asking is to see what authentication a particular user has used to PUSH a commit then you should be able to find it based on the remote URL for the repo.
If you are looking to find out who did a specific commit, you can search for it in the Web UI.
Hope this helps, reach out if you have additional questions.
Currently I am working in a project in which we are using Gitlab for repository management. I am the owner of project so I want to automate the code checkin validation on daily basis . my question is , Is there any option so that, I can configure the daily check(whether developer pushed there code or not) and send the notification to developers?
There is no build in functionality for this.
As this is a reasonable feature you should follow the feature request workflow of Gitlab and open an issue for that. https://gitlab.com/gitlab-org/gitlab-ce
But keep in mind that such feature will be probably only available for the EE version.
As alternative you can use the API of Gitlab to extract the commits of a project. https://docs.gitlab.com/ce/api/commits.html
Then process the date diffs using a e.g. python script and send an email or post on a Mattermost channel using their API. https://api.mattermost.com/
We use Youtrack for our developers, and we have GitLab CE with repos. In several projects we allow external users to post issues in GitLab and I need copy of them in YouTrack. At least initial copy on posting.
Can't find any solution on web. So I guess we need to make our own, but with way is better?
YouTrack project workflows requesting some GitLab API url?
Webhooks? I don't see any web hook receiver on YouTrack side. Is there any web
hook Should U make some thing in the middle?
There're no webhooks available in YouTrack indeed, so your options would be either to use some external service that would copy information from GitLab to YouTrack, or create a workflow that would request GitLab for new issues every once in awhile.