I’m investigating alternatives in my projects for my team (20+ developers). i want something that can be run on server and has auditing (check) that logs
Push
Pull
Clone of projects
I can’t find anything in the docs about this for GitLab community
Does anyone here know if these features are supported? or any plugin ?
Currently, the level of logging you're requesting has not been implemented into GitLabs, but there are plans in place to implement them, though there is currently no estimated time of arrival.
Audit events are richer now, with GitLab 14.3 (September 2021)
Audit events for merge request approval setting changes
Audit events are now created if changes are made to the merge request approval settings
in a project. You can now see if a change is made to the following policies:
Requiring user password for approvals.
Allowing modifying merge request approvals in a merge request.
Needing to get new approvals when a new commit is added to a merge request.
You can now be confident that once you configure approval settings, you can quickly see
if they are changed. This is a great way to show auditors that controls were put in place
and have not been removed or modified.
Thanks to Adrien Gooris from Michelin for this contribution!
See Documentation and Issue.
And GitLab 15.2 (July 2022) adds (for non-CE only)
Audit events for group-level merge request settings
GitLab now records additional audit events when changes are made to group-level merge request settings. These are in addition to project
audit events that record changes to the same settings on projects. Specifically, audit events are now created when changes are made to groups to:
Prevent approval by author
Prevent approvals by users who add commits
Prevent editing approval rules in projects and merge requests.
Require user password to approve
Remove all approvals when commits are added to the source branch
These audit events can help you know that the settings and default configurations for your group-level merge request settings have been put in place correctly and that they have not been changed.
This is especially important because these group-level settings
will cascade down to child projects.
Governance and visibility over these changes will help you strengthen separation of duties and further simplify audits.
See Documentation and Issue.
GitLab 15.2 (July 2022) also propose to audit a special kind of clone: forks.
But only for GitLab Ultimate, so again, not CE.
Streaming audit events for project forks
You can now monitor the project forking inside your groups with new audit events that are recorded whenever
a project is forked. This includes information such as:
The user name of the user that forked the project.
The timestamp of when the project was forked.
Details of the forked project.
This gives you visibility on where your projects and source code are being copied to, and by
whom, so that you can take action if needed.
These events potentially generate a high volume of data, so they are only available as
streaming audit events.
Thank you Linjie Zhang for this contribution!
See Documentation and Issue.
Related
I am using Azure Devops in an IT environment with many different development teams and git repositories. Each development team owns one or more repositories. It's my job to work on various application components contained in said repositories. Because I do not own those repositories, I should not make any changes in build/release pipelines, build policies etc, all by myself because that can impact other people's work.
Now let's say I have a feature branch named UpgradedFeature in the repository FeatureRepository, containing my changes. Said changes also introduce a breaking change in the build pipeline used for that repository for the master branch. Let's say that pipeline is named MasterBuildPipeline.
So in order for my build based on the branch UpgradedFeature to succeed and not impact other people's work, I make a clone of the MasterBuildPipeline, name it UpgradedFeatureBuildPipeline and configure the breaking changes. This new build pipeline is used exclusively by me for the UpgradedFeature branch only.
The build, now using the new UpgradedFeatureBuildPipeline pipeline succeeds and now I want to merge into master , so I make a pull request to merge the changes contained in UpgradedFeature into master. The master branch has a branch policy in place named MasterBranchPolicy like described on https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser. This branch policy contains the MasterBuildPipeline and prevents completion of that pull request when the build using that pipeline does not succeed.
So my problem is that my pull request triggers the MasterBranchPolicy containing the MasterBuildPipeline and not the UpgradedFeatureBuildPipeline containing the necessary breaking changes for the build to succeed. So the build fails and I cannot complete the pull request.
Of course I could edit the MasterBuildPipeline for a short time, introduce my breaking changes, run the build, then discard the breaking changes again. But there's a chance I may impact other people's work with that and somehow I have a feeling that's not the right approach. I could also edit or disable the MasterBranchPolicy for a short time but again, I may impact other people's work and I feel it's not the right approach.
How should I do this?
So the build fails and I cannot complete the pull request.
To complete the pull request even through the build fails, you could grant yourself Bypass permissions. Bypass permissions let you complete pull requests that don't satisfy branch policies. You can grant bypass permissions to yourself then complete the pull request. Here is Bypass branch policies for reference.
Please navigate to Project setting >> Repositories >> The repo >> Security >> user (yourself) >> Bypass policies when completing pull requests.
Then, you can Override branch policies and enable merge even the MasterBuildPipeline faild.
Please also note that use caution when granting the ability to bypass policies, especially at the repo and project levels. Policies are a cornerstone of secure and compliant source code management. In your scenario, it's suggested to edit the MasterBuildPipeline and the MasterBranchPolicy or disable the MasterBranchPolicy as you mentioned.
Generally, workflow of DevOps Branching Strategy as follows
Developer will create a feature or bugfix branch out of develop. One feature or bugfix branch usually stands for one JIRA bug or feature item. These branches are personal
The changes will be pushed into the developer's feature or bugfix branch.
When the new feature or bugfix is complete.A developer will create a pull request. Pull requests open a code review phase.
Once a pull request has been approved, the team lead or development team will move it into development.
When the development branch has all the epics and bug fixes, i.e., the content planned for the next release, the development team or team lead will create a release branch. This initiates the release regression testing phase.At this stage, only bug fixes are accepted for release, and the workflow is similar to that of the development branch.
Having a separate release branch will enable future development towards the next release in the development branch. Features for the next release are not included in this release. However, bug fixes for this release will be incorporated into the development of the next release as well.
When release content meets the criteria, the release branch will be frozen, which means that it ends. Content from releases will be merged to master and tagged there. For the next release, a new release branch is created when needed.
As per my experience, I would suggest creating branching policies like
A pull request is requested to merge the develop, release, and master branches.
Pull request approvers should be leads.
All developers can create feature branches.
All developers can push to hotfix and feature branches. Commit messages must include the JIRA issue id.
GitHub dependabot security alerts may sometimes become a chore especially when an abandoned project that is no longer in active use receives frequent security advisories. Is there an option to disable the active security monitoring?
Open you repo and go to Settings. Click on Code security and analysis in the Security subsection. There you will find dependabot settings with a Disable button for turning off the automated advisories.
The page is also available through direct link https://github.com/<USERNAME>/<REPO>/settings/security_analysis by replacing placeholders <USERNAME> and <REPO> with the corresponding identifiers.
Note that disabling the advisories will negatively impact the security of your software and should be avoided for any software with production deployments.
This is the top result on google.
I'm sick of getting alerts from dependabot. I have dependabot alerts disabled on all my repositories.
However, I think what we are not getting dependabot alerts but pull request alerts.
Even if we disable dependabot alerts, it continues to create pull requests.
Since we do want to receive pull request alerts, we get them.
In the official dependabot repository there are people commenting on how to disable it but all the links are outdated. Now most of them lead to the documentation or to parts of the options not related to dependabot.
At the moment I have found two possible solutions:
disable security updates:
https://github.com/settings/security_analysis
OR
Delete/truncate the dependabot configuration file:
https://github.com/USERNAME/REPOSITORY/blob/master/.github/dependabot.yml
(change USERNAME and REPOSITORY as appropriate)
I have not yet been able to verify that it works but I think that I will not receive any more PR from dependabot and, therefore, I will not receive the emails either.
Cyberixae's answer should work but if you're getting these alerts on a forked repository, I found a good fix here that involves deleting the dependabot.yml file in a different branch and setting that branch to the default branch.
The documentation for Dependabot version updates > Configure dependabot.yml > open-pull-requests-limit demonstrates how to disable version updates by setting this option to 0. Example .github/dependabot.yml file content:
version: 2
updates:
- package-ecosystem: "mix"
directory: "/"
schedule:
interval: "weekly"
# Disable version updates for hex dependencies
open-pull-requests-limit: 0
Just removing this file from the repository (as the official Github documentation about "Disabling Dependabot version updates" says) did not work for me.
We recently migrated to GitLab Self Hosted (V14.3.0)
We migrated 100+ repos to Gitlab and then we realized, by default only maintainers have write access to Gitlab protected branched.
Is there a way to change the following setting in one shot for multiple repositories or we will have to manually change for every repository?
We want to change "Allowed to merge" from "Maintainers" to "Developers + Maintainers"
In the main group we have set it to the following, I was hoping that this will make it work but no luck -
Well manually will be a bad approach, but the GitLab API offers a lot of functionality regarding that problem. I will not write the script, but i will outline you the APIs you can use and why you use them.
Fetch a list of all projects you want to change - the Projects API
GET /projects
With this endpoint you will receive a list of all the projects within you instance, on which the user has access - be aware that this is a paginated request - so just calling it once will not be sufficient.
Adapt the Protected branches - the Protected Branches API
With the project IDs from the first part you can now query each project and change the protection. We ended up with first deleting the protection and recreating them, because it has proven to be easier.
Anyway i recommend to automate this with a script, and do it rather sooner than later. As some projects might start with custom protections, and this can make the migration harder.
the GitLab API offers a lot of functionality regarding that problem
Actually, GitLab 15.6 (November 2022) does provide said API:
Update access levels from Protected Branch API
Previously, the UI was required to update the access levels of protected
branches. The API required you to unprotect, then reprotect, a branch when
updating its access levels.
Now, the
protected branches API
enables you to directly update which users or groups are allowed_to_push, allowed_to_merge,
allowed_to_unprotect, and more.
This one-step method decreases the risk of a bot
changing this setting and leaving a branch unprotected.
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.