Is there a way to notify people on changes to specific files after they get merged into the Repo on GitHub? Specifically, there is a private repo that we have, with multiple people on it.
We'd like to be able to figure out a way to send emails for the files that people may be interested in, alongside the changes to those files.
Almost every solution I have found online seems to deal with public repos. Such as GitHub File Watcher, RSS feeds, and some of the other options given here. The most promising seems to be Commit Hawk but that is for slack integration. Post-receive hooks apparently do not work with repos hosted on GitHub, and CODEOWNERS seems to require code reviews from whoever gets notified, since it designates them as owners of the files in question.
It is possible to use GitHub Actions for this.
This allows you to run code on every push. That code can then check the changed files and send E-Mails (or other notifications) to users that should be notified.
How you could do this
The commit SHA of the old version (before the push) can be obtained using ${{ github.event.before }} and the commit SHA of the new version (after the push) can be obtained using The commit SHA of the old version (before the push) can be obtained using${{
github.event.after }}`.
Those commit hashes can then be compared with the command git diff --name-only ${{ github.event.before }} ${{ github.event.after }}.
Those changes could then be processed and an E-Mail sent to the people you want to notify.
My action
I have created an action that does exactly this.
You basically create a workflow like this:
name: 'Notify users on file change'
on:
push:
branches: [ master ]
jobs:
notif:
runs-on: ubuntu-latest
steps:
- uses: danthe1st/email-filechange-notif-action#v1
with:
# Address to send E-Mails from
senderEmail: ${{ secrets.SENDER_EMAIL }}
# optional, The subject of the E-Mails to send
subjectLine: 'GitHub file change notification'
# A file in the repository or HTTP address that contains file patterns with E-Mail addresses that should be notified on file changes
mailingList: ${{ secrets.MAILING_LIST }}
# The SMTP server used to send E-Mails
smtpServer: ${{ secrets.SMTP_SERVER }}
# optional, The SMTP port used to send E-Mails
smtpPort: 587
# The SMTP user name used to send E-Mails
smtpUsername: ${{ secrets.SMTP_USER }}
# The SMTP password used to send E-Mails
smtpPassword: ${{ secrets.SMTP_PASSWORD }}
Aside from creating the workflow file, you need to set up the secrets with information about your E-Mail server and let mailingList point to a text file formatted like this:
/path/** some#email.com
/path/to/fixed/file someone#example.com
*.md yet.someone#else.com
Related
I have a workflow, that does some modifications on the repository, and pushes it, expecting the push workflow to start. Now I know that the intended way in the documentation suggests me creating a PAT, but that seems like a hacky solution to me, since the whole build procedure is tied to my account being active and having necessary permissions.
It also expects my account to have push access to my main branches, which I don't want to have. I want to operate through PRs.
Do I have any other options? Do I need to create a my-github-bot account in my org and create a PAT for that? All these options seem too hacky compared to just having a switch to enable workflow triggering with the default ${{ secrets.GITHUB_TOKEN }}
The workflow that pushes can also use the workflow_dispatch trigger on the second workflow to start the other workflow. Either by doing a REST call or by including a call gh:
gh workflow run {{workflow.yaml}} --ref {{sha}} --repo {{owner/repo}}
Or use one of the available actions to invoke the workflow after your push step.
For example:
- name: Invoke workflow with inputs
uses: benc-uk/workflow-dispatch#v1
with:
workflow: Another Workflow
You can also use a GitHub app, there's a special action for that. You grant the app the permissions to invoke the workflow and then let the workflow retrieve a token to invoke the other workflow if needed, heck, you could even use that token to do the push.
- name: Get Token
id: get_workflow_token
uses: peter-murray/workflow-application-token-action#v1
with:
application_id: ${{ secrets.APPLICATION_ID }}
application_private_key: ${{ secrets.APPLICATION_PRIVATE_KEY }}
- name: Use Application Token to create a release
uses: actions/create-release#v1
env:
GITHUB_TOKEN: ${{ steps.get_workflow_token.outputs.token }}
with:
....
A bit of setup is required to register the app and give it the right permissions.
I have a simple Node JS application built in the build directory using yarn and trying to deploy on GitHub Pages using GitHub Actions using crazy-max/ghaction-github-pages#v2 actinon in the simplest form:
- name: Deploy
uses: crazy-max/ghaction-github-pages#v2
with:
target_branch: master
build_dir: build
env:
$GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
(Note I deploy to master because the repository name is equal to the <<username>>.github.io)
To my surprise, it fails on the following error:
Error: You have to provide a GITHUB_TOKEN or GH_PAT
The whole message is not helpful as long as I know the GITHUB_TOKEN is automatically generated with each build.
The repository has the following settings under Action:
Actions permissions: Allow all actions
Fork pull request workflows from outside collaborators: Require approval for first-time contributors
Workflow permissions: Read and write permissions
The whole token and permissions management in GitHub is overkill for simple projects and the documentation lacks sample settings and the reader only goes down the rabbit hole.
How to get this run?
Based on the documentation I'm reading, it looks like you need to remove the leading $ from your environment variable name you are setting
Like this:
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Documenation:
https://github.com/crazy-max/ghaction-github-pages
I would like to use a GitHub action/do some config that automatically requests a review from a team in a GitHub organization (for example core). I know that you can create pull request templates that automatically request a review from a certain reviewer but how do I do this without creating a template? In summary, I would like to have a team in GitHub core automatically requested a review for each PR opened. How do I do this?
In general, this is a good use case for the code owners feature: you could have a file .github/CODEOWNERS that looks like
* #yourorg/core
This requires a review from that team on any pull request opened.
However, this requires the team to have write permissions on the repository, and (as per comments) the intention is to not give this team write permissions.
With the team having only "triage" permissions, this could be achieved with the following workflow:
name: Request review on PRs
on:
pull_request:
types:
- opened
jobs:
request:
name: Request reviews on opened PRs
runs-on: ubuntu-20.04
steps:
- name: Create PR review request
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh pr edit ${{ github.event.pull_request.html_url }} \
--add-reviewer yourorg/core
This runs on each opened pull request and creates a review request from the yourorg/core team using the pr edit command of the GitHub CLI, which is pre-installed on the virtual environments.
I have a repository which contains deploy keys. I want a workflow job which periodically checks whether any of the deploy keys are reaching their maximum allowed age before they must be rotated. I tried writing a workflow like this, using the GITHUB_TOKEN, but it looks like it doesn't have the necessary privileges. My repository belongs to a GitHub Organization.
name: Check age of repository deploy key
# This workflow is triggered on pushes to the repository.
on:
push:
schedule:
# Runs 06:00 every day
- cron: '0 6 */1 * *'
jobs:
expiry_check:
env:
DEPLOY_KEY_METADATA_URL: https://api.github.com/repos/my_org/my_repo/keys
DEPLOY_KEY_MAX_AGE: 3600*24*365 # 1 year
# This job runs on Linux
runs-on: ubuntu-latest
steps:
# GitHub repository checkout
- name: GitHub repository checkout
uses: actions/checkout#v1
- name: Check if any deploy keys are approaching their expiry data
run: |
python3 -c "import requests;import sys;url=sys.argv[1];token=sys.argv[2];r=requests.get(url, headers={'Authorization': f'Bearer {token}'});print(r.text)" $DEPLOY_KEY_METADATA_URL ${{ secrets.GITHUB_TOKEN }}
The response to my API request has this error: {"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/reference/repos#list-deploy-keys"}
Is there some other solution to this problem, besides personal access tokens and GitHub Apps? The first option is not feasible; business logic can't break when an employee leaves the GitHub Organization. I suppose I could make a GitHub App, but I'd rather avoid that too, if I can. I'm not an admin in my GitHub Organization.
Currently I have the following code:
name: Build-All
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build-linux-64:
name: ${{ matrix.config.name }} Build
runs-on: ${{ matrix.config.os }}
strategy:
fail-fast: true
matrix:
config:
- os: ubuntu-latest
name: Ubuntu 64
other_linker_flags: '-m64'
arch: x86_64
output: myLib.so
steps:
- name: Make fake file
run: |
echo "hello" > ${{ github.workspace }}/test.txt
- name: Uploading Release
uses: ollydev/upload-release-action#master
with:
repo_token: XXXXXXXXX
file: '${{ github.workspace }}/test.txt'
asset_name: "test"
tag: autobuild
owner: '${{ github.repo.owner }}'
repo: 'B'
overwrite: true
and two repos: A and B.
Repo A has the above yml jobs and it is a private repo. It has all the code, compiles it, and wants to push the release to repo B which is public.
To do this, I created a new github account My-CI and I added it to both the private repo and the public repo. On that new account, I then created a Personal access token with scope: public_repo
and that's it. The code works.. but is there a way to NOT have to create a separate account just to give it access as a CI to both repos? IE: Is there a way that I can create a token on my real account that is read-only for one repo and read-write for another? OR maybe create a github app token or something that can only upload releases for the one repo (B)?
As you've implied, you can't limit the scope of a personal access token to different scopes for different repos. Theres a few ways of doing this.
Intermediate, public storage
The first is to upload the artifacts to an intermediate place, accessible from anywhere, e.g. Dropbox, Docker Hub, etc. Then you can manually trigger a github action in your public repo to pull this artifact back down and create a release from it. To manually trigger this action you could use the repository_dispatch event either using cURL / postman locally (with an access token auth bearer) or using something like https://www.actionspanel.app/ which is a github app which allows you to manually trigger github actions using repository_dispatch, with parameters so your download link would be a parameter.
Personal access token
The simplest option is still a personal access token though. Your workflow above has repo_token: XXXXXXXXX which makes me wonder if you know about github secrets? Ideally this token would be stored in a secret then accessed using ${{ secrets.BRANDONS_TOKEN }}. I would ask why you are worried about a personal access token. If you use github secrets and are careful about the 3rd party code you pass the token to (you may not want to simply pass your token to #master, for example), it should be fine.
GitHub Apps & Webhooks
GitHub apps or webhooks would be another way, you can authenticate those on a per-person basis and per-repo basis but you'd need an application running online to receive and parse the messages and its quite a big piece of work.
(Probably not) GitHub Deploy Keys
Another thing to be aware of is Github Deploy Keys, you can use these to obtain read/write access to a single repository without an account attached. You would then store this deploy key in a secret in the settings of the other repo. However, I'm not sure you can trigger releases with deploy keys - they are not bound to an account so I'm unsure who's username would be visible on the release history.