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.
Related
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.
When i open pull request via github.com ui, sometimes ci.yml workflow isn't running
ci.yml:
The pull requests are merging into protected branches.
to my understanding, since there is "on" pull request", it should happen on every pull request/
But in reality, the pr's are waiting for status check to be reported, but since its not occuring, the pr's just wait for the cli check forever.
so basically, since there is a requirement for the cli check to pass, but its never even running in the first place, the pr is stuck.
Since in the Checks tab of the pr i cant even see the check, it means its never taken into consideration
The solutions ive seen only explain how to force the pr to make the check, and while they sometime dont even work, I want to fix it so it"l never happen in the first place
Appreciate the help!
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.
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.