googleapis / repo-automation-bots

A collection of bots, based on probot, for performing common maintenance tasks across the open-source repos managed by Google on GitHub.

Repo Automation Bots

A collection of bots, based on probot, for performing common maintenance tasks across the open-source repos managed by Google on GitHub.

Implemented Bots

Name	Description	Install
auto-approve	Automatically approves and merges PRs matching user-specified configs	install
auto-label	Automatically labels issues and PRs with product, language, or directory based labels	install
blunderbuss	Assigns issues and PRs randomly to a specific list of users	install
cherry-pick-bot	Cherry-pick merged PRs between branches	install
conventional-commit-lint	PR checker that ensures that the commit messages follow conventionalcommits.org style	install
do-not-merge	PR checker that ensures the do not merge label is not present	install
failurechecker	Check for automation tasks, e.g., releases, that are in a failed state	install
flakybot	Listen on PubSub queue for broken builds, and open corresponding issues	install
generated-files-bot	PR checker to notify if you are modifying generated files	install
label-sync	Synchronize labels across organizations	install
license-header-lint	PR checker that ensures that source files contain valid license headers	install
merge-on-green	Merge a pull-request when all required checks have passed	install
policy	Check repo configuration against known rules	install
release-please	Proposes releases based on semantic version commits	install
release-trigger	Trigger releases jobs	install
repo-metadata-lint	Lint .repo-metadata.json files	install
snippet-bot	Check for mismatched region tags in PRs	install
sync-repo-settings	Synchronize repository settings from a centralized config	install
trusted-contribution	Allows Kokoro CI to trigger for trusted contributors	install

Development environment

You need to install node.js version 12 or higher.

To manage multiple Node.js versions, you can use nvm.

Running the app locally

Create a Proxy to Relay Webhooks

In order to forward to your local machine, you can use smee.io. Visit https://smee.io/new and create a proxy for relaying webhooks to your local web-service. After creating the proxy, you'll get the URL of the new proxy.

In the root directory of repo-automation-bots, run:

npm run proxy -- -u <URL-OF-PROXY>

Creating the Development Application

If it's your first time running your application, you should create a new GitHub application using the probot server:

1. cd packages/your-bot.
2. npm start.
3. visit: http://localhost:3000 and install.

Granting the Development Application permissions and events

1. By default there will be no permissions. Visit https://github.com/settings/installations, click configure, then 'app settings'.
2. Navigate to Permissions and Events. You likely need 'Repository > Pull Requests' for permissions.
3. You also will need to subscribe to events (bottom of page). For instance, if your bot responds to PR activity, the 'Events > Pull Request' should be enabled.

Install the bot on a repo

1. Follow the link to install the app and navigate to 'Install App', if installed on the organization you desire (likely yourself for testing), click the gear.
2. Under permissions ensure that there aren't pending requests to be approved
3. Under repository access select only select repositories. Select the repository you wish to test against.

Running Your Application

Once you've created your application, and installed it on some of your repos, start probot again, setting the following environment variables. Most can be found at github.com/settings/apps/{YOUR_APP}:

• APP_ID: the ID, listed near the top, App ID: 12345
• PRIVATE_KEY_PATH: path to App's private key, you can request a new one be created and downloaded at the bottom of the page.
  • Alternatively, set the GitHub client ID and secret:
    • GITHUB_CLIENT_ID: client ID from the top of the page.
    • GITHUB_CLIENT_SECRET: client secret from the top of the page.
• WEBHOOK_SECRET: secret key set in GitHub developer settings. Edit this to a known value in the settings page.

Environment variables set, run:

1. cd packages/your-bot.
2. npm start.

Running bots on a Cron

To run a bot on a schedule include a file in your bot's folder named cron whose content is valid unix -cron format. This will create a Cloud Scheduler Job which makes requests to your endpoint at the specified schedule.

Publishing Utility Modules

1. create a token with Wombat Dressing Room.
2. run npm run release.

Overall Architecture

repo-automation-bots's Issues

FR: add Stackdriver metric for remaining quota

We'd like to be able to track our available quota and be notified if we are running low on requests. With added cron support, we are interested in our quota usage

Cloud Build failing for header-checker-lint

Step #0 - "build": src/header-checker-lint.ts:25:28 - error TS7016: Could not find a declaration file for module 'minimatch'. '/workspace/packages/header-checker-lint/node_modules/minimatch/minimatch.js' implicitly has an 'any' type.
Step #0 - "build": Try `npm install @types/minimatch` if it exists or add a new declaration (.d.ts) file containing `declare module 'minimatch';`
Step #0 - "build": 
Step #0 - "build": 25 import * as minimatch from 'minimatch';
Step #0 - "build": ~~~~~~~~~~~

Not sure why it's passing CI, but failing here.

conventional-commit-bot: allow for commits longer than 72 characters

Infra: Create Email or Issue on failing bot based on OWNERS file

Due to the mono-repo nature of our project and our deployment pattern, there is no "baked in" way of forwarding errors that occur in a Bot to the given owners of a bot without subscribing to the "firehose" of all errors (like I have).

I propose that we create a serverless job that when an error occurs, it parses the bot the error occurred in, looks up who the OWNERS of the bot are via a code OWNERS file in this repository, then creates an issue assigned to those owners.

Extra credit would be to send an email to the owners in addition to the Issue, though that has other implications.

A problem I can see with this is accidentally including PII or other sensitive information in the created Issue. The body of the Issue may need to be ran through DLP before creating it, or we may need to have a "generic" body with a short stack trace to minimize this risk.

trusted-contribution: Add configuration file

As mentioned in comment at https://github.com/googleapis/repo-automation-bots/pull/114/files/f432c262d2344b20717c24357e1f71f2578c186e#diff-f8fbe6dc6a42af4c5efddeeeab43531bR34

We should add configuration file support to allow users to specify the trusted contributors.

A thing to also think about before implementing: would it be useful to restrict the file/filetype editable by each account? For instance, renovatebot should only ever need to edit package.json files.

the default import for a bot in `app.ts` should convert `-` to `_`.

rather than updating our deploy scripts to stop replacing - with _ let's update our bot's default import.

(when we started looking at taking on this work, it would have required that we update basically every bot that's deployed so far, and would have been a big pain).

see: #218

Create new bot template

For folks who want to create a new bot, we should provide an easy mechanism to scaffold out a bot.

Release Please Bot should trigger CI

I was looking at this PR created by the release-please bot:
googleapis/sloth#328

And noticed that it didn't trigger a kokoro run. I'm not sure what Kokoro uses to decide if jobs should be run, but we should find a way to have PRs created by our bots automagically trigger CI if applicable.

New Bot: Merge on Green

When an ‘automerge’ label is applied, after all required GitHub status checks pass, and the PR is approved, it will be automatically merged.

Build Cop: group issues for related tests when it makes sense

Is your feature request related to a problem? Please describe.
If 10 Go subtests of a single test all fail, you get 10 separate issues filed at the same time.

Describe the solution you'd like
Group subtests into a single issue. We could do this by splitting the test name on "/" and only keying on the first part. Not sure how this would affect other languages.

Describe alternatives you've considered
Keep all of the issues separate. This is very noisy.

Additional context
https://github.com/GoogleCloudPlatform/golang-samples/issues?utf8=%E2%9C%93&q=is%3Aissue+%22bigquery%2Fsnippets%2Fquerying%3A+TestQueries%22+label%3A%22buildcop%3Aissue%22

New Bot: Lock stale issues

Lock issue and PR threads that are closed, and days old.

buildcop: allow not sending XML for full build failures

gcf-utils: make bootstrapping initial bot deployment easier

Currently, you need to:

1. manually create a KMS keyring
2. manually create a Key in the keyring
3. manually assign encrypter/decrypter permissions on the new key

Bot request: startblock

Create a Probot version of Startblock

New Bot: Triage me

Label untriaged issues with a "triage me" label.

Use the Google 'G' Logo for app

The GitHub Apps we have created under dpebot all have the default github app logo. It would be nice to use the official Google 'G' for these :)

Copyright header linter doesn't allow for date ranges

The official style guide specifies that:

• Old copyright dates may not be removed
• New copyright dates may be added in a range format (e.g. 2019-2020)

If e.g. one splits an existing file into several separate files, the copyright should say "2019-2020", but the current linter doesn't allow that. It can't parse the dash, and it wants to see the most recent year for added files.

Add Stackdriver Logging and Error Reporting

The framework (gcf-utils) currently silently discards errors.

Add Stackdriver logging and error reporting to the framework.

conventional-commit-bot: linting should be case insensitive

test dependencies differ from deployment

When developing and running tests (locally and on CI), tests can pass while deployment fails.

An example is the release-please bot passed tests, but at deployment time, we discovered that it's missing @types/semver.

Parallelize Cloud Build steps to speed up deployment

We can parallelize the deployment of each bot to speed up deployment.

License header check should allow ignoring files

trusted-contributions: force-push to PR branch does not trigger bot

renovate-bot has a feature to rebase/retry the PR which does a force push to its branch. This does not seem to trigger an event that the trusted-contributions bot listens to.

Cron support

We're quickly realizing that we like cron an awful lot. Would be awesome to have a cron ability with the existing bot framework tied into cloud scheduler.

Synthesis failed for repo-automation-bots

Hello! Autosynth couldn't regenerate repo-automation-bots. 💔

Here's the output from running synth.py:

Cloning into 'working_repo'...
Switched to branch 'autosynth'
Traceback (most recent call last):
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 256, in <module>
    main()
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 196, in main
    last_synth_commit_hash = get_last_metadata_commit(args.metadata_path)
  File "/tmpfs/src/git/autosynth/autosynth/synth.py", line 149, in get_last_metadata_commit
    text=True,
  File "/home/kbuilder/.pyenv/versions/3.6.1/lib/python3.6/subprocess.py", line 403, in run
    with Popen(*popenargs, **kwargs) as process:
TypeError: __init__() got an unexpected keyword argument 'text'

Google internal developers can see the full log here.

Disable esModuleInterop

Ideally, we should not need esModuleInterop configuration for tsconfig.

New Bot: Close abandoned issues

For issues where we ask for more information and the opener never responds.

Allow bots to have hyphens in their names when created with generate-bot

Today, if you run the generate-bot and attempt to name a package with a hyphen ('-') it will fail.

✔ What is the name of the program? · trusted-contributions
✔ What is the description of the program? · blah
✔ This package will be saved in /packages/yourProgramName unless you specify another location and directory name here relative to /home/crwilcox/workspace/repo-automation-bots :  · /package/trusted-contributions

You used an invalid character, like a hyphen or an integer. Please try again.

While not necessary, it is a convention we have used to this point. It would be great if we could extend the generator to support this.

feat: Switch cloudbuild to use sh files and add tests.

Our cloudbuild.yaml uses a lot of complex bash. Let's pull the bash steps out into various scripts that can be tested and verified.

• pull cloudbuild steps into scripts
• test the scripts

improvement: stop using types from octokit

We keep bumping into types incompatibilities between Octokit and probot; Let's look into instead using the types exporte by probot.

related: #89

CC: @orthros

New Bot: Label sync

Provide a common set of labels (name and color) that can be enforced in all repositories across an organization.

FR: Status check to tell me if I'm breaking cloud.google.com

We keep our samples for cloud.google.com and developers.google.com on the GitHub. I have several times broken samples, deleted region tags, or moved files in a way that cloudsite was unable to publish due to my changes. It would be awesome if I had a GitHub status check that told me when I was about to break things.

The devrel samples tracker should have much of the data we need :)

release-please closed a PR it did not open

release-please bot closed a PR that it did not open. The PR updated a dependency in the setup.py.

See googleapis/python-storage#45

New Bot: Propose/start a release

When there are changes to master, propose a new release.

header-checker-lint: should look for configuration in .github

it looks for configuration in .bots currently.

New Bot: Translate issue

Occasionally, we receive GitHub issues in non-English languages. This bot could comment on an issue or another comment with a translation if possible.

header-checker-lint: cannot view more details

See PR https://github.com/googleapis/nodejs-monitoring/pull/305/checks?check_run_id=245512794

Following View more details on License Header Lint GCF link sends me to https://us-central1-repo-automation-bots.cloudfunctions.net/header_checker_lint which says 'Bad Request'.

Have rule for verifying commit includes tests for new code

We've had a number of commits into the python-docs-samples repo recently from contributors who are not including tests. It'd be great if we had a bot that enforced coverage / tests for new code.

One approach could be to also use the nox --missingtests functionality.

nock for probot config requires extra mocks for 404s

When mocking a 404 for context.config('filename'), we need to do something like:

      const requests = nock('https://api.github.com')
        .get(
          '/repos/<owner>/<repo>/contents/.github/release-please.yml'
        )
        .reply(404)
        .get(
          // why is this necessary?
          '/repos/<owner>/.github/contents/.github/release-please.yml'
        )
        .reply(404);

License header checker should only look in headers

Example: googleapis/gcs-resumable-upload#256

This file has a string that matches the copyright header regex and is resulting in an incorrect failure.

python-docs-samples missing API labels

Was trying to do some triage over here:
https://github.com/GoogleCloudPlatform/python-docs-samples/labels

Noticed that none of the api: labels are getting automatically created for that repository. Not sure why :)

update license headers in bot generation

We've been moving our template towards license headers with a // prefix rather than /*, see: #184, we should update our bot generation script accordingly.

New Bot: Build cop

Manage issues for failing unit tests.

• Pub/Sub support in the proxy.
• A bot to consume the Pub/Sub events, parse test output, and manage issues.
• Docs: how to publish, what format, etc.

cc @sofisl @bcoe @orthros @dzlier-gcp @fhinkel

feature: PubSub triggers

Similarly to Cron Support; there are events from other services (e.g. Kokoro) whose job completion may trigger the invocation of a bot.

Proposed changes:

Bots

• A bot that wants to subscribe to PubSub triggers needs to include a topic file in their source folder
• A bot that wishes to subscribe to PubSub triggers needs to subscribe to the topic.repository event in the appFn:

 app.on('topic.repository', async context => {});

Infrastructure

• The build process will inspect all bots && if a bot has a topic file and no corresponding PubSub topic it will
  • Create a PubSub topic whose name is the bot name
  • Create a Push Subscription for the topic and point it at the Cloud Run serverless-scheduler-proxy instance. NOTE: This will use a custom ServiceAccount that has permissions to invoke the CloudRun instance.

serverless-scheduler-proxy

• Move the cron processing endpoint to /cron (was /)
• Add a new endpoint /pubsub which handles incoming PubSub push messages of form:

// PubSubMessage is the payload of a Pub/Sub event.
type PubSubMessage struct {
        Message struct {
                Data []byte `json:"data,omitempty"`
                ID   string `json:"id"`
        } `json:"message"`
        Subscription string `json:"subscription"`
}

• This handler parses the name of the bot from the Subscription field, and creates a new HTTP request to the bot/Cloud Function whose name is in the subscription. This request will be signed using the signing key of the bot in the x-hub-signature header, and the x-github-event header will be topic.repository

Build Cop: include enough information for making a report actionable

Sample issue filed by build cop: GoogleCloudPlatform/python-docs-samples#2800

It seems that the source log link is only available once all testing is concluded, so it's a bit confusing when it files issues that can't be acted on immediately. In this case, its four hours later and the bug is still unactionable as the build is still in progress

Consider adding a link for another source (e.g. sponge/sponge2) or deferring issue creation until the artifacts are ready.

trusted-contribution: Don't run for repositories without kokoro

This bot is currently running on repositories without kokoro which is a bit awkard.

We can look if there is a .kokoro folder present and if so add the label instead of doing it just on contributor.

header-lint-check: Failing for a deleted file

See https://github.com/googleapis/google-auth-library-nodejs/pull/867/checks?check_run_id=387631481

When a file (samples/iap.json) was removed, the header lint check reports the file as having a missing header.

New Bot: Repo settings sync

Provide a common set of configuration settings that can be shared across all repositories in an organization.

New Bot: Surface area semver diff labels

For languages that support static analysis, identify breaking surface area changes and label the semver version change required to accept the PR.

New Bot: Delete merged branches

This bot would look for branches used by PRs that have been merged to master, and delete them