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.
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!
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.
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 Coursera course Version Control with Git, I encountered a problem below:
Which one of these statements is true?
A pull request must be made from a forked repository.
A pull request can be made only when a branch is being merged.
A pull request can act as a form of review and approval.
From my perspective, both 1 and 3 are correct.
Can someone point out which choice is correct, which are incorrect, and provide reasons?
A pull request can also be made on your own repository by members of that project, so the first choice is not correct.
A pull request can also be made between commits, tags, and earlier points in time, so the second choice is not correct.
The third point is true. So that's the answer.
Your question is technically about Github, not Git. Git doesn't have pull requests.
Third one statement is true. because we can create pull request without being merged and can be created without fork a repository. And we create a pull request for review the changes first then we're going to merge them into repository for which we created pull request.