A GitHub App built with probot that
integrates with civicrm.org
services.
# Setup environment
cp .env.example .env
vi .env
# Install dependencies
npm install
# Run the bot
npm start
On the CiviCRM server infrastructure, the env variables are in the systemd unit: /etc/systemd/system/probot-civicrm.service
(botdylan VM).
The probot docs provide a number of useful tips on development setup, unit testing, etc.
If you want to patch probot-civicrm
and this is your first foray into probot, be sure to read Developing an app. It introduces a nice workflow. You can skip the code-generator ("Generating a new app") and instead clone this repo. Then proceed with the remaining setup ("Configuring a GitHub App", etal). These steps will enable you to run/develop locally with your own copy of the bot.
This service is primarily intended for use by approved projects in the CiviCRM ecosystem. Consequently, there is a whitelist of repos from which the bot accepts notifications. All other notifications are silently ignored.
See also: config/_COMMON_/repo-authz.js
The bot will automatically post a comment when someone opens a pull-request or issue in Github. The comment is in a Markdown file which may include Mustache variables.
For example, in each subscribed repo, you can create files like these:
.github/ISSUE_REPLY_TEMPLATE.mustache.md
.github/PR_REPLY_TEMPLATE.mustache.md
If you want to manage the templates in a centralized fashion, you can
create templates inside this bot's config
folder:
config/:owner/:repo/:template
config/:owner/_COMMON_/:template
config/_COMMON_/:template
Templates from the most specific folder will take precedence.
NOTE: For civicrm.org, some templates are copied to multiple repos. After updating
civicrm-core/PR_REPLY_TEMPLATE.mustache.md
, rn./update-config-copies.sh
to update the others.
A number of variables are defined by default (as appropriate to the event):
{{issue.number}}
{{pull_request.number}}
{{pull_request.base.label}}
{{pull_request.base.ref}}
{{pull_request.base.repo.name}}
{{pull_request.base.repo.full_name}}
{{pull_request.head.label}}
{{pull_request.head.ref}}
{{pull_request.head.repo.name}}
{{pull_request.head.repo.full_name}}
{{repository.owner.login}}
{{repository.name}}
{{repository.full_name}}
Additionally, you may create variables.js
plugins in any of these locations:
./config/:owner/:repo/variables.js
./config/:owner/_COMMON_/variables.js
./config/_COMMON_/variables.js
For example, on repos that participate in civicrm.org
's
continuous-integration, these variables are also available:
{{ci.test_host}}
{{ci.browse_test_url}}
Variables from the most specific folder will take precedence.
The plugin extpr
listens for pull-requests on on CiviCRM extension
projects, and it relays them to Jenkins for processing.
There are few key configuration items:
- (Environment)
JENKINS_URL
- Credentials for connecting to the Jenkins server - (Environment)
STATUS_SECRET
- An internal config option used to generate tokens. - (Environment)
STATUS_CRED
- When Jenkins sends back status info, it should authenticate by submitting a username:password pair.
After the PR has been tested, you may request a new test run by posting a comment which includes this line:
/test
By default, the bot only tests PRs submitted by collaborators
on the repository. If a PR is submitted by someone who doesn't have sufficient access, a collabrator can trigger a test per above (/test
).
(TODO: More real-world testing of this.)
As part of a GSoC project by @kartik1000, the bot can do a few other special tricks:
- Adding a comment
/label [add|remove],[label-name]
will add/remove labels to the issue - Referencing a Gitlab issue under
dev/xx
will make the bot add a comment to the issue (this might be missing some configurations) - When a PR is merged, it will close the associated Gitlab issue (same as above)