Details¶
Here are the details of what the bot does.
When a pull request is opened¶
The bot gets notifications from GitHub when a pull request is created in the organizations and/or repos where it is configured. It’s currently configured in the edx and openedx organizations.
A number of aspects of the pull request are examined:
The author is looked up in the contributors database
The title of the pull request might have indicators
The bot has to choose:
The GitHub labels to apply to the pull request.
Pull requests fall into a number of categories, which determine how it is handled:
If the author is “internal” to the pull request’s GitHub org (as determined by the author’s institution affiliation, and the institution’s “internal-ghorgs” setting in orgs.yaml), the bot only applies the CLA check. No comments are put on the pull request, and no Jira ticket is created.
If the title of the pull request indicates this is a blended project (with “[BD-XXX]” in the title), then this is a blended pull request.
Otherwise, this is a regular pull request.
Additionally, if the pull request is in draft status, or has “WIP” in the title, it is a draft pull request.
Now we can decide what to do:
Initial status:
Blended pull requests get “Needs Triage”.
For regular pull requests, if the author doesn’t have a signed CLA, the initial status is “Community Manager Review”. If they do have a signed CLA, it is “Needs Triage”.
Draft pull requests start with a status of “Waiting on Author”. The initial status determined above will be set once the pull request is no longer a draft.
Labels:
Blended pull requests get “blended” applied as a GitHub label.
Regular pull requests just get “open-source-contribution” as a GitHub label.
The initial status is set as a GitHub label on the pull request.
Initial bot comment:
Each kind of pull request (blended and regular) gets different comments.
If the user doesn’t have a signed CLA, the bot adds a paragraph about needing to sign one.
Other information:
A GitHub commit status called “openedx/cla” is added to the latest commit. This is applied to all pull requests, even ones by authors internal to the pull request’s organization.
When a pull request is closed¶
On internal pull requests, the bot leaves a comment asking the author to complete a survey about the pull request.
When a pull request is being closed, it will be considered an internal pull request if it has no “open-source-contribution” label, on the assumption that it was processed when it was opened, so the lack of a label means the author was internal at the time the pull request was created.
When a pull request is re-opened¶
The bot deletes the “please complete a survey” comment that was added when the pull request was closed.
Adding pull requests to GitHub projects¶
The bot will add new pull requests to GitHub projects. Projects are specified with a string like “openedx:23” meaning project number 23 in the openedx organization.
Regular non-internal pull requests get added to the project specified in the GITHUB_OSPR_PROJECT setting.
Blended pull requests get added to the project specified in the GITHUB_BLENDED_PROJECT setting.
Individual repos can specify other projects that external non-draft pull requests should be added to. The projects are listed in an annotation in their catalog-info.yaml file:
annotations: # This can be multiple comma-separated projects. openedx.org/add-to-projects: "openedx:23"
The bot never removes pull requests from projects.
Making a Jira issue for a pull request¶
The bot used to automatically make Jira issues for pull requests, but no longer does. Now a Jira issue will be created if a specific label is added to the pull request.
The bot is configured to know about a small handful of Jira servers, each with
a short “nickname”. If you add a label of jira:xyz
to a pull request, the
bot will create a Jira issue in the Jira server with the “xyz” nickname.
Each Jira server can specify a mapping of repos to other Jira details such as the Jira project for the issue, and the issue type to create.
Jira issues created this way will have a “from-GitHub” Jira label applied.