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?
Related
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.
I know how to require status checks to pass before merging, but I am looking to just require them to complete, regardless if they pass or not.
Specifically, we have a unit test check that runs on every pull request. We do not want to block merging if they fail, but we want the developer to be required to see the results before merging the branch. Right now they can merge it in the middle of running unit tests.
Do you know any way to do this? I have reviewed the github documentation and can't find anything other than the standard branch protection rules, which does not have this option. Thank you for your help!
P.S. There was a similar question posted here, but it was never answered and the poster never clarified.
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!
I'm quite new to GitHub and I'm not sure how I should behave about the number of pull requests I send to a certain project.
Is there such a thing as too many or too frequent pull requests?
Are there general guidelines to follow?
The naming convention for a pull request is your own to make.
The idea is to make a small coherent change that can easily be merged back and tested.
By "coherent", I mean "which introduces only one change or new feature".
It is best to isolate that change in its own branch, that you will push to your fork, and from which you open a new PR: see "couple of tips for PR".
You usually should have one pull request per issue. You should also squash your pull requests to a single commit. Your commit message should be very specific.