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!
Related
I don't want to subscribe a slack channel to all issues on arbitrary third party repositories, just to the particular issues on which my team/organization is involved (contributing to / impacted by), so the usual github integration command /github subscribe thirdparty/arbitraryrepo issues does not suffice as it would cause a ton of unwanted noise in the channel. (and the existing label filtering would not cut it)
(Update: there is an open feature request for that https://github.com/integrations/slack/issues/1280)
I neither want to forward my personal github subscriptions to the slack channel as there are lots of projects I am individually involved that have nothing to do with my team's work. (e.g. my direct mentions)
Also, subscription should stay despite I leaved the team/company.
A per-issue public RSS/Atom feed would cut it but it does not exist.
Am I missing something obvious?
The only workaround I can think of is adding a channel email integration, registering that address to an organization-shared github account and subscribe it to the individual issues we run into.
But this is quite cumbersome (must keep an alternate github logged-in session while browsing, channel readability could be abused to hijack company account, subscriptions can't be managed from the slack channel...) so any different idea would be very welcome.
As far as I know there is nothing that would suit your need completely at this moment, but have you considered labels?
#1 option You could use filtering based on label which seems to be the closest:
That would notify you about all issues, pulls, commits, releases, deployments that has a given label. Syntax example:
/github subscribe repo-owner/repo-name +label:"team-a"
Pros: a general filter based on a label name, e.g. team-a
Cons:
a single label filter only (AFAIK: multiple labels aren't supported but discussed: https://github.com/integrations/slack/issues/384)
this works only for a label given when issue/PR is created. Not during its existence ("change label" events are not triggered). Known bug (https://github.com/integrations/slack/issues/1594) and feature PR is open https://github.com/integrations/slack/issues/965
Note: a workaround to get info about label change in PR: to convert PR to a draft and back (https://github.com/integrations/slack/issues/965#issuecomment-1330884166)
#2 option Another thing that might be considered is that the account that is used within GitHub Slack app for connecting to Git server will be actually notified also about all its mentions, assignments & reviews! So if you don't use your personal account, you could get generated some related notifications to the whole team / other specific user etc.
EDIT:
Workaround steps to achieve partially what you want (but it can be in some conflict with your Slack / GitHub settings that I’m not aware of):
Use / create a shared account (or other special account) in GitHub
In Slack, use this special GitHub account for connecting Slack GitHub app to GitHub (this enables notifications by default for this account - mentions and assignments).
Then, when this GitHub account is assigned / mentioned, you’d automatically get notified (but again, then it would work not just for issues but hypothetically also in PRs etc.) to a dedicated channel where you'd have your GitHub integration set.
To auto-assign an issue, you'd have to use e.g. GitHub Actions.
Caveat: But as we discuss, there’s no simple way to achieve your goal completely. To at least get closer to something similar to what you describe and require, you’d need to accept some compromises and extra steps for workaround as it’s unfortunately not currently natively supported. 3rd hypothetical way is to create even more complex mechanisms of filtering & redirecting data which would be increase a level of complexity to just introduce but also maintain (unless you'd already have something similar existing in your infrastructure) and I wouldn't recommend it.
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.
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.
I'm a bit surprised to learn that Github doesn't seem to allow the creation of a pull request between two identical branches. Is there a rationale to this? We have been building a workflow using WIP Pull Requests, and not being allowed to do this is annoying. We want to create the pull request at the beginning, in anticipation of future work to merge.
Is there a way to do it that I'm not seeing?
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.