I wish to trigger an action(maybe send a mail/alert) when the code is committed only for my team members which is a very small subset of large number of contributors. Is there a way to track commits only from certain specific users in Github/Gitlab.
Yes! You can even automate this process using a webhook. In case you aren't familiar - a webhook delivers a JSON payload when a certain event occurs.
By setting up a webhook on the GitHub push event you'll create alerts every time a push is made to your repository. You can create a small script that scans the author value. If the value matches one of your team members you can configure your alert/mailer, otherwise you can configure your script to ignore the webhook's payload.
Related
Currently, we're using an organization-level generic-webhook for all our repo.
Recently we had added new repo repo. which needs to be use only repo level generic-webhook for some reason.
Is there any way, So that i can call only repo level generic-webhook and ignore organization level webhook ?
I don't believe there's any way to do this. GitHub delivers a lot of webhook events and users generally want them delivered right away. In order to make webhook delivery as speedy and efficient as possible, there aren't any filtering options on GitHub's side. You're expected to receive all the events you're subscribed to and filter them yourself.
If you want the organization-level webhook to not operate on this particular repository, you'll need to configure your service that receives the webhook itself not to act on those messages.
Does anyone know if you can trigger a webhook based on the github action of creating a new branch called
Release-xxxx where XXXX can be anything? I only want to initiate this webhook on that new branch name.
In general, GitHub webhooks cover a single large category of activities that you are then responsible for filtering. In your case, you can install a webhook to be notified when a new branch or tag is created and then perform the filtering yourself.
GitHub doesn't perform the filtering for you because filtering is expensive and there are a lot of operations to notify about. This is no different than reading an events stream API and having to select only the events that you're interested in.
Is it possible to configure Github actions workflow to merge pull request if it was approved (submitted review with approve keyword) by one of the users (static fixed list, which can be written in workflow config file)? I tried to find it in documentation: https://help.github.com/en/articles/workflow-syntax-for-github-actions#on
- I suppose I can use on: [pull_request_review] trigger for action, but documentation didn't mention how to access event payload in action yaml file, where I need to extract reviewer login from this payload.
I found this in https://help.github.com/en/articles/virtual-environments-for-github-actions#filesystems-on-github-hosted-machines:
workflow/event.json: The POST payload of the webhook event that triggered the workflow. GitHub rewrites this each time an action executes to isolate file content between actions. Use the GITHUB_EVENT_PATH environment variable to access this file.
So the next step will be figuring out how to parse a JSON file and extract some data that a later step can use. For that, looking at GitHub's setup-dotnet action might prove useful. In line 62 of installer.ts, they call a function called core.exportVariable, which as you can see here, causes ##[set-env name=NAME;]value to be printed in the action's output. I've personally verified that this causes the environment variable called NAME to automatically be present in later steps of the same workflow job.
Now, I don't yet know if you can simply do echo "##[set-env name=NAME;]$VALUE" in a run step of a GitHub workflow and have that work; it's possible that you'll have to write a custom action in Typescript to get access to core.exportVariable. But once you have parsed the JSON, that would be one way of passing that information on to later steps in your job.
In addition of rmunn's answer, you might also want to protect your branch:
GitHub Actions: Prevent GitHub Actions from approving pull requests (2022, 14th Jan.)
We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests.
This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.
To prevent breaking existing workflows, Allow GitHub Actions reviews to count towards required approval is enabled by default.
However, an organization admin can disable it under the organization's Actions settings.
That way, you are sure approvals were made exclusively by users, not by other actions.
I want to create a GitHub web hook that scans the names and contents of the files being committed, and disallows a commit if a specific token appears in either.
I have found the GitHub webhook documentation, and it is clear that there are many events that can be caught, including the push event. There is a lot of data available in the JSON object that is sent with the push event, including the commits array, which is "An array of commit objects describing the pushed commits. (The array includes a maximum of 20 commits. If necessary, you can use the Commits API to fetch additional commits. This limit is applied to timeline events only and isn't applied to webhook deliveries.)"
However, it is not clear how to turn this into a list of filenames and file contents.
How do I do that?
A webhook is a server-side hook which simply calls any URL you want with a JSON payload.
That means the actual hook (listening for the webhook) will live anywhere you want (meaning, not on GitHub side)
And don't forget that, by the time the hook is triggered, the commit has already been pushed and cannot easily be "refused" (maybe reverted?)
Your webhook listener can pull and list files in a local repo which will be used for analysis.
Plus, the git pull will pull all the commits pushed, not just "an array of 20"
And it can use said local repo as gateway, pushing the commits pulled to a final target remote repo, if their file content match your policy.
That is another way to "accept" or "refuse" commits in a webhook scenario.
I have 3 related github repos, with associated issue trackers. I'd like to get email when anything happens in the issues, but not whenever someone pushes, or makes a pull request. I don't see the ability to control notifications at this level of granularity.
I know that I can unsubscribe from specific threads, but that doesn't give me what I want either.
Alternatively, if there was a way to tell which type of notification it is in the email, so I can set up a filter, that would be fine too. However, I haven't been able to determine a consistent difference on that front either.
That's not possible currently using the features GitHub offers. However it may be possible using GitHub API.
I'd like to get email when anything happens in the issues, but not whenever someone pushes, or makes a pull request.
All Pull requests are issues but not all issues are Pull requests. That's being said, you cannot [currently] unsubscribe from pull requests and get the issues, since the pull requests are issues.
Since you are developer you can develop your own app to notify you (send you emails) when new issues are opened to specific projects.
Taking IonicaBizau/git-stats as example, you can access the issues like this:
https://api.github.com/repos/ionicabizau/git-stats/issues
You will get 304 Not Modified if there are no new issues. That way you can check if there were added new issues or not. Checking if the issue is pull request is done by checking if there is a pull_request field in the object, like mentioned here.
An alternative that I just found, is the Message-ID field of the email. the pull and merge emails all have <org/repo/pull/....> the issue emails have <org/repo/issue/....> so, I can filter on the Message-ID field.