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.
Related
I have multiple GitHub checks. One of them is mergify. It merges the PR is all defined checks are successful. However in my case there is a different check that only starts after a minute or so, which is why mergify always misses it.
How can I make sure that mergify starts with some delay or better that it starts as the last GitHub app
You can't and should not do that.
If you wrote your Mergify config with something like "#check-failure!=0" or #check-pending!=0 this is exactly why the Mergify documentation states that you should not do that.
The only secure way to merge a pull request automatically is to list all the CI you expect to pass to have it merged.
Requiring that my test is in check-success worked.
What criteria does Github use to determine whether or not a given PR "has too many changes" for rebase-merging?
I've worked on a refactoring effort recently and after submitting and getting approval in the PR, I got the following message from Github's UI, preventing me from rebase-merging the change:
This branch cannot be rebased due to too many changes
At the time, I had no idea what exactly the limit was, so I split my ~30-commit PR into 2 ~15-commit changes, which made the restriction go away.
I found a question around the same limitation, but it doesn't focus on what these limits are, asking for workarounds instead:
This branch cannot be rebased due to too many changes
I'm now doing another change which also has a similar number of commits and wanted to know exactly what rules Github uses to determine whether or not a given PR "has too many changes" so that I can split my PRs accordingly upfront and avoid rework both on my end as well as on reviewer's.
I tried finding official documentation on this to no avail. Unfortunately, the only way I'm aware of to test it is to submit the PR and check if the message comes up. This however becomes unfeasible since the message only shows after all checks have succeeded, meaning I have to also get actual reviews on the change to check whether they are mergeable or not. If I then find out it is not mergeable, I have to create a separate PR and split the change, wasting everybody's time on re-reviews.
Many different aspects (or a combination of multiple aspects) could be the cause for this:
Number of commits
Number of affected files
Number of affected lines
Number of conflicts with base branch
etc
I've been using GH for a long time and had never seen this message until a couple weeks ago, so I assume it is either some new feature, or maybe a restriction depending on the type of plan used by my company.
This is almost certainly a timeout-based situation. GitHub uses libgit2 to perform rebases and how long a rebase takes depends on the number of commits, the complexity of the changes in each of those commits, and the complexity related to the repository (size of objects that must be looked up, etc.). libgit2 doesn't have all the optimizations of regular Git, but regular Git cannot rebase in a bare repository, so the use of libgit2 is required.
So there's no fixed limit in the number of commits or the complexity, only that if it takes longer than whatever the timeout is, the operation will fail, and you'll be left with that message. One way to avoid this is to use regular merge commits, which while not immune from timing out, are less likely to do so because the merge involves only three commits, not however many are in your branch.
I know github generally has a rule where PR's and stuff can be closed, but never deleted to preserve history, unless there is something very necessary about it (such as private keys being included in the PR by accident, etc.). I was wondering, however, if draft PR's can be deleted. Sometimes I use it for certain CI/CD testing, and I end up closing them, but they can start cluttering up my PR history. Since they were never converted to a full, real PR, is that a thing we can do without contacting github support?
Thanks!
Apparently no. Draft PRs are treated like regular PRs and cannot be deleted without contacting support. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository. They only delete them if there is sensitive data.
You might want to setup a separate repo just for CI/CD testing if you are trying to test configurations like Actions. That would keep your main repo from getting cluttered.
If you are creating draft PRs to run tests, that could indicate your tests are difficult (or slow) to run locally. I'm just assuming though. I know that's why I sometimes reply on CI/CD instead of local testing.
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?
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!