Hey I have Gitlab CE version and I would like to implement a job that verifies approvals from a peer. I know this feature is totally available for premium and ultimate versions. However, I already created a little hack that verifies that the person who approves the MR is different from the one who created it.
My question is: is there a way to cancel the approval, without being manually, if there has been a change to the code?
is there a way to cancel the approval, without being manually, if there has been a change to the code?
This is already the default behavior in GitLab. When new commits are pushed the source branch of an MR, all approvals are removed.
However, if that setting is not available in GitLab Free, there is no workaround for this as only the approver can revoke their own approval. You might be able to make a pipeline job remove the approval using the API, if you have a personal access token for every approver available in the job, but this is quite impractical.
Related
I am trying to set up a GitLab workflow for my project.
When someone writes on a feature branch and completes that task, that person creates a merge request.
In our team, we have created a checklist that represents the definition of done.
So when someone creates a merge request, one of the other developers has to do a code review and check all the items on the checklist.
Are there any tools for GitLab that will automatically comment the merge request and display the checklist in the comment. Also, the merge request should be blocked until another developer checks off all the items on the list?
We are a university research group and use a free version of the self-hosted GitLab instance with version 14.9.1
I know this looks like a dumb question, but I just found out that, last month, something terrible happened to my GitLab instance: someone signed up on it and became admin himself, without my invitation, as I was the only administrator. So he wiped off every internal and/or private project inside of it, groups too (and I don't even know whether he had stolen all of them before erasing or not, I'm worried because they were proprietary code). How did it happen? Does this have anything to do with, since the version was CE-13.3.0? If so, would version upgrading be enough to be safer, or should I make some particular configurations, such as disabling sign up page?
It is best to follow "GitLab instance: security best practices", which does include indeed:
Ensure open sign-up is disabled on your instance.
Open registration is disabled by default on self-managed instances with GitLab 13.6 and above installed.
If new sign-up is enabled and your instance is open to the internet, anyone can sign up and access data.
Administrators who would like to further restrict access on their instance can follow our documentation on how to configure user access.
Regarding the CVE mentioned, follow also "Action needed by self-managed customers in response to CVE-2021-22205", in your case: "CVE-2021-22205: How to determine if a self-managed instance has been impacted" (unless the log events have been wiped out as well).
As an admin of a private GitLab instance, it would be great to know when new versions are available, especially for security updates.
I couldn't find a way to subscribe to a "newsletter" of new releases and how important it is. How can I do it?
GitLab releases a new version monthly, always on the 22nd of the month. This way you don't need to subscribe.
Still, if you would prefer a notification from GitLab, I would recommend to subscribe to their release newsletter here. It has two e-mails each monthy.
Use the release notification from project page: https://gitlab.com/gitlab-org/gitlab
click on bell and select custom, then you can choose New release. have pfun ;)
volker.
GitLab releases a new version every single month on the 22nd. You can check our blog here and release notes here. You can also check what's coming in our upcoming releases.
I am having a hard time finding a definitive answer on the internet. Is there a way to customize GitLab notification emails? For example, when a pipeline has passed, I want to give more precise information than the ones provided by the default sent email.
If it's not yet implemented, from where comes the email parameters (e.g., branch, commit)? I don't understand how they work.
Thanks!
We have a CI/CD setup in Azure DevOps that gets triggered from push on master branch. Is it possible to make the approver the user that was the cause of the build trigger?
The idea behind this is that we have many developers in our team so I want the specific dev that pushed changes make the decision on whether or not they want the changes deployed, vs. a dedicated approver.
Short answer, no.
Context:
This is the opposite of a good practice, which is why there's an option to require someone else to be the approver, but not the person who made the change. You don't want the person who made a change to be the one to approve it, because that enables a single person to sneak a change through. This means that mistakes can slip through, or even intentionally malicious changes.
The best practice is to require someone other than the person who made a change to review and approve the change.
While I totally agree with #Daniel Mann on why this shouldn't be done, the way I've seen it happen is that the Team is assigned as the recipient of the approval request, and the user requesting a release or deployment should not approve it checkbox remains unchecked.
Then to avoid the inbox noise of the approval request, turn off the notification for the team about pending release approvals.
EDIT
If you must have only that one person assigned as the valid user to approve changes for deployment, you could do this too, but it wouldn't be pretty. You could have a "stage" per person. These stages would use artifact filters in the pre-deploy conditions to only send approval email to the person that stage is for.
After the approval it forwards to the actual deployment stage to do the work.
Now you need to add the username or something as the tag on the build. I'm unsure if there's a tool/task to do this as part of the build pipeline to keep it continuous, but I know you could figure out how to do it from the REST api. Perhaps you would need to create a pre-approval stage that runs a PS script to access the REST api and tag the provided build with the value of requestedBy property on the build.
Again, see how hard it is to do this? That probably means you're not following best practices. "Make the right things easy and the wrong things hard." -Unknown