This question already has answers here:
Is there a way to make Github un-approve a pull request if a new commit is pushed to the branch?
(2 answers)
Closed 1 year ago.
We have have programmers on our team that make changes after the Code Reviewers approved.
Is there a way in Github, everytime a new file/edit is committed, Github would Automatically reset and ask Code Reviewers to reapprove?
Currently programmers are adding new changes without approval, and this may affect the QA and Production system later.
GitHub has an option for this in the branch protection settings, which is “Dismiss stale pull request approvals when new commits are pushed.” That controls whether the approvals are removed, and while it doesn't specifically re-request approvals from the reviewers, they will receive the normal notifications that changes have been pushed, and they can choose to re-review when it's convenient. Of course, the submitter can always click on the button to explicitly request a re-review.
Note that, as mentioned in the comments, there are various reasons to allow this practice, since sometimes there are minor improvements that could be made, but the status quo would be acceptable nevertheless. However, in some environments, this cannot be allowed for compliance or policy reasons, so this option exists for those cases.
Related
In certain cases, I am able to express all of my change requests for a PR solely through "propose changes" comments. In these cases, if the author simply accepts all proposed changes, I would certainly change my review to "approve".
As far as I can tell, currently the author must:
Accept proposed changes
Re-request review
Wait for me to see the request and review
Merge
The third step can introduce a big delay, and it is unnecessary because if the proposed changes were accepted then I'm definitely going to approve. Is there a way to automate this in Github?
We currently have a GitHub repository where our master branch is protected for everyone except admins, who are able to commit and push directly to the branch without first opening a pull request. We're looking to find a way to send a Slack notification anytime an admin commits directly to master in order to call attention to the fact that there was an override of the branch protections. This may happen intentionally due to extreme circumstances or, worst case, by mistake (which will need to be addressed).
This seems like it'd be possible with a combination of the GitHub Slack action, the if key on the job/step definition, and ideally some piece of information from the push event JSON.
The last part is where I'm stuck: I don't see an obvious way to use the data contained in the push event to differentiate between one-off commits that would violate our branch protection policy and a normal/compliant pull request.
Does anyone have any ideas as to whether or not this is possible? Perhaps there's another event that I should be attaching this workflow to that would give me the information I'd need to tell the difference and launch the Slack notification?
In general, using GitHub Actions to do this kind of notification is problematic because the user can simply remove or neutralize the code that reports this and then push to the main branch. The Actions workflow that's used will be the one pushed into the repo as part of that commit, so this won't be an effective control.
You'd want to probably instead use a webhook to notify a service of this fact and then look at the HEAD commit, parse the commit message to extract the PR number, and verify that the second parent of the commit is the same as the head of the PR. Note that this won't work if you're using squash merges, because there's no easy way to verify that the commit created by a squash merge is the same as the one created by the branch from which it was created.
What is the best practice (and why) on closing tickets/issues in the versioning/ticketing system during software development?
Our workflow is based on creating FEATURE or PATCH branches to implement changes and then merge into a controlled master that is (mostly) guaranteed to build and be ready for deployment.
Our ticket system holds bug reports or feature requests we subsequently fix/implement in said branches, then merge into master before the next release.
Which solution is better:
A. Close the ticket once the solution is implemented (and verified) in the FEATURE/PATCH branch. This cleans out the list of open tickets fast and gives a good overview off how much work is left for the next release.
B. Keep it open until the branch has been merged to master and verified there.
Only master represents the final product, so technically only now the work is done. And no bug might stay un-fixed because someone forgot the merge.
My experience is that a support ticket with a feature request is closed after the request is logged with the Product Manager, they acknowledge with a time-frame and the customer has been suitably advised.
For a patch, both are valid approaches, but depending on when the fix is liable to be applied. If it's liable to be a fix-pack release within two weeks: keep the ticket open until the patch is deployed to that customer. Use the ticket as the root for the change management system. Otherwise, if the fix will not be deployed until some future routine release, then my advice is to let the customer know accordingly, and close the ticket.
Research I've done before raising this question:
[github] single user pr - no relevant results
[github] single user pull request - no relevant results
[github] approve own pull request
github protected branch require pull request (Unanswered)
A potentially relevant question, but around a multiple user environment, so there were workarounds. I don't have a workaround.
'[github] approve own pr` - no relevant results.
Quite a few Google searches
So my problem is simple: I have a personal GitHub repository that I am using to manage my website code. I would like to prevent accidental check-ins to the master branch because I do not want the CI/CD pipeline that I'm building to trigger unless a feature is complete; I'm planning to use issue-linked feature branches to handle updates.
My problem is that I cannot seem to set this up without having someone else to approve the pull requests, which I don't have. So the question is: How, other than creating a secondary git account to handle PR's, can I protect a branch to prevent accidental check-ins from happening, without having someone else on my team to approve those pull requests?
I know that I can do this in Azure Repositories, however, I quite like the GitHub environment so I'd rather do this in GitHub.
I managed to work around this. At the time I made this request, I didn't have automated tests set up (Something I believe all projects should have for completeness). When I set up validation requirements to merge into Master, I could not directly check-in to Master because those checks had not been run.
I could still approve the PR myself, so that was allowable, however, I also had to ensure that all pipeline checks had completed before that PR could complete.
It's not a complete answer because if you are not running a CI/CD pipeline with test running you will not be able to take advantage - but it's easy enough to set something dummy up that will always pass to enable this solution. Until GitHub.com provides a self-approval allowance, it seems to be the best answer.
I'm always happy to hear alternatives though!
On Github, I've noticed that some pull requests say that they're "Good to merge" because they have passed a Travis build passed. I have used Travis a little bit, how does it integrate with pull requests on Github?
Here's a screenshot of what I'm talking about:
Once you've set up Travis and tell it which branch need to be tested, it'll automatically run a build on each pull request targetting one of those branches (and every commit pushed to these branches).
Note that the Travis notification on Github only appears after the build/test is over (roughly 15min).
Also, this isn't Travis specific. Github has an API for continous integration, works for TravisCI, also works with CircleCI.
Note that since December, 8th 2014, you can see multiple status from multiple services on your pull request.
See results from all pull request status checks
Since we introduced the Status API, you've been able to improve the quality of your code by including the status of a pull request within the conversation timeline, for every push.
Before today, you've only been able to see results from one service. Now you can see all your results at once, from multiple CI systems that test your code against different platforms to simultaneous security testing and code coverage analysis.
You can also see how the status of a pull request has changed over its history by clicking the icons listed next to individual commits.
Since July 20th 2015, that status information will be clearly visible in the PR.
See "Clearer mergability information for Pull Requests":
Each month, 119,000 repositories on GitHub use automated status checks (via the GitHub Statuses API) and it’s important that this information is presented in a way that you can easily understand.
When you’re ready to merge a pull request, you should be able to see that it is ready.
If a check isn’t passing, you should be able to see why.