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.
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.
We have two developers using the same ADF. Each developer creates a git branch and starts working on it. Each developer can save the changes to their own git branch but there can only be one collaboration branch and this branch decides the publishing branch. This is causing a blockade (for one of the developer. How can we solve this ?
ADF publish branch can be set using a publish_config.json but now there is an option to set this in the adf itself. which one takes precedence? What is the best practice here?
You need to manage the work of each developer with standard git branch/merge processes. When one dev is done with work in their feature branch, then they will create a pull request to merge changes into your collaboration branch.
If the second dev has not created a feature branch yet, they can just do so after the pull request from the first dev is complete and then continue work from there. If the second dev has already created a feature branch, then they will need to merge the new changes from the collaboration branch into their feature branch to continue work before later committing to git and creating a pull request to merge changes from their feature branch back into the collaboration branch. From there, you can publish as needed.
This git work can be done through the ADF editor as well as through any other git interface you have. It's up to you.
This article discusses the process in specific detail using the ADF editor.
EDIT:
I believe you now have answers for this from 3 of the other 5 questions you posted about this same topic in the past day.
ADF publish confusion in git mode
Azure data factory working-branch confusion
When ADF publish branch is git protected how to publish?
Here is another article which describes the fundamental git process for ADF to help bring you up to speed with the fundamentals of how the different branches work, and how you can switch publish branches on the fly if needed.
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.
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.
I'd like to get a list of users who have starred my public repo and a number of fields related to them such as whether or not they have cloned it. Is this possible with the Github API?
The endpoint for stargazers is:
https://api.github.com/repos/:owner/:repo/stargazers
for eg, if you want to get users who starred the repo https://github.com/suhailvs/django-schools/ you can use:
https://api.github.com/repos/suhailvs/django-schools/stargazers
The endpoint for stargazers (users who have starred a repo) is documented here in the documentation. You can follow with additional requests on those users.
Checking whether people have cloned a repo is impossible (you don't even need to be logged in to clone a git / GH repo). You can, however, list the forks of a repo.
Github webhook services are fairly detailed and you can really get a lot of information from them but gleaning if someone cloned your repo is a bridge too far. As far as I'm aware, there's no way to track that (you can track new forks). I'd recommend using a webhook to track new repo watches to accomplish at least some of what you're looking for.
Axibase has a tool which leverages Github webhooks, and notifies you via email or instant message (through the messenger of your choice) when someone stars your repository.
The underlying process is here:
It's a quick setup, the whole process takes less then 10 minutes. Basically you need to create a plaintext file with your email / messenger credentials on your local machine, launch an ATSD sandbox from the terminal, and paste the webhook generated at runtime into the appropriate field on Github. The full process is here.
Disclaimer: I work for Axibase