For every PR open > 72 hours, go through all review comments; if there’s no comment by a listed reviewer yet, assign oppia-dev as an assignee of the task. This is recorded in metrics and the reviewer is pinged. This needs to be checked on a daily basis

Per oppia/oppia#11042 (comment), would it be possible to separate out the error messages for the following specific cases:

• PR was made from a develop branch
• PR was made from a branch whose name is prefixed with develop
• PR was made from a branch whose name is prefixed with release
• PR was made from a branch whose name is prefixed with test

This will help prevent the confusion that was noted in oppia/oppia#11042 (comment).

Oppiabot should tag PRs with builds passing but last commit > 2 days ago, with a warning message / label saying “build might be stale, please update from develop”. Then reviewers/authors can take a closer look, and if someone introduces a new check, they can look at PRs with this label and restart the checks if it makes sense.

At the moment, the CLA check is triggered when a PR is opened. It then checks whether the author of the PR has signed the CLA. This check needs to be extended so that whenever a commit is pushed to a PR, the bot checks whether the author of that commit has signed the CLA. This is to prevent cases like: oppia/oppia#5490 (review)
We also need to take care of the number of API calls the bot makes for this extended functionality.

Replace probot stale with probot scheduler since we are currently using a fork of probot/stale which isn't updated and is using old dependencies of probot, probot-config which have deprecated functions.

Context and Motivation

The E2E team has been introducing new expectations for PRs that modify the E2E tests, for example rerunning the changed tests 5 times to make sure they aren't flaky. Using Oppiabot to leave reminders on these PRs would help contributors remember these new processes.

Desired Behavior

Oppiabot leaves a comment on every PR that affects the E2E tests. These are all the files owned by U8NWXD in the CODEOWNERS file. This comment should include a list of reminders of the codeowner checks documented in the wiki. For example:

• You will need to provide screenshots showing that the tests aren't flaky after your changes.
• All constants should be in all-caps.
• All element selectors need to be at the top of the file except for certain cases in utility files and with chained selectors.
• Everything that requires a globally unique name should be given a reliably unique name.
• All it blocks should be independent from each other.
• Use waitFor functions before interacting with any element, or use a utility from the actions.js file.
• No await keywords for .first(), .last() or .get(i) calls.
• Put reused or generally useful code in functions.
• Variables should be named as nouns, and functions should be named as verbs.
• All HTML classes you reference in root selectors in the tests should begin with protractor-test-.

For more details, see the E2E test wiki page

Come up with a robust definition of “stale” that works for our codebase, and make oppiabot handle this correctly so that PRs like #6138 are not missed.
The third party stale app needs to be modified.

We are seeing a lot of response time errors on Heroku: https://dashboard.heroku.com/apps/murmuring-castle-33250.
These errors are resulting in checks being flaky even though the implementation is correct. One of the occurrences was with a CLA check where it did not work on a PR but when investigated later, worked fine.

• One of the possible reasons for this is the large number of new checks which were added during GSoC.

• We need to dig deeper into this and find out why these errors are occurring.

  • The way to do this would be to add support for custom logging for oppiabot since Heroku logs are only preserved for 24 hours and we are not able to investigate what is going wrong.

• Once we are sure, we can look into increasing the number of dynos if required.

note the start of the second line, there is "@vojtechjelinekto", it should be "@vojtechjelinek to"

As a fix for #19, we've decided to take incremental steps to ensure that each PR has a changelog label. Therefore, if a PR does not have a changelog label, the bot will ping the author to fix it but will not close the PR.
A repo check, similar to TravisCI should be implemented as a next step, if the former does not work, to ensure that each PR has a changelog label at time-of-merge. Oppiabot should be more of a helper rather than an enforcer, in this case.

Enforce lint tests in oppiabot repo.

A bug was noticed on the code owner check oppia/oppia#10534.
After investigating, the issue is that when checking for new code owners, we don't ignore comments. And the above pull request added comments in the code owner file that included user names.

#82 (comment)

We take force-pushing a PR under review quite seriously -- it makes it hard for reviewers to go through the changes made in the PR.
The aim of this issue is to add a double-confirmation message in the pre-push checks before a developer is able to force-push commits onto a PR.
We can have two confirmation messages with a YES or NO something along the following lines:

• You are trying to force-push commits onto a feature branch. If there is a pull request using this branch, which is under review, this will overwrite history on GitHub and make the incremental changes harder to review. Are you sure that you want to force-push?
• If the answer for the above question is YES, then ask: Are you really sure that you want to force-push?
• Only if the answer to the above question is YES, allow force-push.
  (Please note that we're open for ideas here!)

See the following on how to detect force-pushes: SO Post and Sample script

Add the Oppia LICENSE text to all files in the project.

Oppiabot should automatically record which codeowners are not following the 24 hour response time.

If there are contributors who are not listed in either the onboarding tracker or on the CLA, alert the onboarding team.
This should be done for both issues and pull requests, using probot.

We would like any PR that is merged into develop to have a "changelog: -type-" label. This is to help organize the changelog easily during releases.

PRs must contain exactly one changelog label, and the bot auto-close the PR if no label is found. It will leave a top-level comment asking the PR author to add a changelog label before reopening the PR.

The Oppia Android project has a lot of branches that are stale. They could either be because a PR was already merged for that branch (although now Github should automatically delete those), or if a branch is not being used for a while.
It would be a good idea for oppia bot to flag those branches (maybe branches that are x days old), notify the owner of the branch that the branch will be deleted in a few days if the branch is not actively used, and then delete the branch after those many days if the branch remains inactive.

Add automation to detect any PRs which affect the datastore layer (maybe using github actions or oppiabot).

I investigate the test failures and I was able to fix some of them. Others are failing for legitimate reasons, which is why I created this issue.

1. The scheduler gets created at

   oppiabot/index.js

   Line 11 in 6d723a9

   scheduler = createScheduler(robot, {

   , but in the tests, the app (oppiabot) is initialized

   oppiabot/spec/oppiabotSpec.js

   Line 16 in 6d723a9

   oppiaBotPlugin(robot);

   before robot.auth gets mocked

   oppiabot/spec/oppiabotSpec.js

   Line 82 in 6d723a9

   robot.auth = () => Promise.resolve(github);

   and the scheduler calls robot.auth https://github.com/probot/scheduler/blob/8ad237c69116894a5579d360e544f2586191fa7a/index.js#L77 before it is mocked so it calls the actual robot.auth and not the mocked implementation.

A possible fix for this would be to mock robot.auth before initializing oppiabot. I did that and it fixed the initial problem but provided another problem: the mock github data which is being resolved misses some data required by the scheduler.
2. Before every event gets dispatched, we check if the repo owner is allowed to run the bot

After fixing the above issues, 8 tests pass and 6 fail.
3. This test

After adding of eslint and fixing of all the files, we need to have eslint to check on pre-commit.

The following functions in the checkIssueAssignee module are performing the same functionality as in the apiForSheets module: hasSignedCla, checkAssignees, and need to be refactored to use the functions in the apiForSheets module.

Note that the functions in apiForSheets might need to be refactored support usage in both modules.

Oppiabot should close the PRs if CLA isn't signed instead of just leaving a comment and adding label. This will ensure that such PRs aren't merged even accidentally. This is required since it would be messy if such a PR is merged and we have to revert it back.

Upgrade googleapis version to the latest issues. This requires to be tested well since the upgrade can be a breaking change.

When a new PR is created, Oppiabot seems to keep assigning the wrong reviewers to it. See e.g. oppia/oppia#9389 (comment). These reviewers need to subsequently be manually removed, which causes confusion.

Would it be possible to fix the algorithm for this so that someone from the list of codeowners is always assigned (perhaps the person who owns the most files / "changed lines" in the PR)?

/cc @ankita240796 @jameesjohn

The handling of job-related PRs by oppiabot is broken. Please revert and fix accordingly. For more details, please see the comment at oppia/oppia#9546 (comment).

Also, please note that the formatting is off. Make sure you have one blank line separating each paragraph.

/cc @ankita240796

The bot should assign the corresponding project owner once it finds a project label on a PR. The bot should also leave a message saying “Assigning to @xxx for the first-pass review.”
If no project label is found, the bot will close the PR and ask the author to add a project label to the PR before re-opening it. In this way, all open PRs will always follow the review cycle.

Since yarn is a more intelligent package manager with much more functionality than npm and installs every package that npm can, it is worth researching a move to use yarn.

Our npm packages are quite out date, this issue is to log the upgrade of the npm packages.

A lot of times we have PRs where all the reviewers have LGTM'ed but the continuous integration tests are still running. On oppia-web, we label those PRs with a 'PR: LGTM' label and the author is expected to merge the PR once the tests pass.
It may be useful to have oppia bot scan PRs with this label, and check if the tests are complete and have passed. If the tests have passed, it can automatically submit that PR.
I am not sure if Github allows bots to submit PRs, and also we need to think about the final commit that is dependent on who merges the PR.

Currently in Oppia-Android, we follow up with the inactive contributors by following these steps:

1. Follow up with student after 7 days of no-activity by commenting on issue and sending an email.
2. If they reply within next 7 days, great, else after 7 days (2 weeks at this point from start), close the PR and mark student as lapsed.

Instead this follow-up process should be automated via oppia-bot.

This is a feature request to update & set up the bot to work on https://github.com/oppia/oppia-android. I think right now all we need is the CLA tracking support, but we may request/add additional, Android-specific functionality in the future.

I'm happy to make the changes if folks point me in the right direction. :)

The CLA check should auto-close PRs if the contributor has not signed the CLA with a proper message on the following lines:

Hi! @{author}. Welcome to Oppia! Can you please could you follow the instructions [here](https://github.com/oppia/oppia/wiki/Contributing-code-to-Oppia#setting-things-up) to get started? You'll need to do this before we can accept your PR. I am closing this PR for now. Feel free to re-open it once you are done with the above instructions. Thanks!

I see the following error in oppiabot logs. This looks unrelated to our code-setup and is coming up from the probot-config instead.

Here are the logs:

ERROR event: context.github.repos.getContent is not a function
TypeError: context.github.repos.getContent is not a function
at loadYaml (/app/node_modules/probot-config/index.js:28:49)
at getConfig (/app/node_modules/probot-config/index.js:91:24)
at forRepository (/app/node_modules/probot-stale/index.js:52:24)
at unmark (/app/node_modules/probot-stale/index.js:23:27)
at Application.<anonymous> (/app/node_modules/probot/lib/application.js:156:50)
at step (/app/node_modules/probot/lib/application.js:44:23)
at Object.next (/app/node_modules/probot/lib/application.js:25:53)
at fulfilled (/app/node_modules/probot/lib/application.js:16:58)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:97:5)

The bot should make sure that the points in the PR checklist are followed. (Things like title must have an issue number, and the description must say "Fix #bug_no").

This should not be a blocking check, as there may be instances where this doesn't apply, like the routine update of translations PR, or the update AUTHORS PR every release.

I think a one time notification on the PR thread, if the PR fails this check, should be good.

Add a check to automatically notify devs (by commenting on their PR) if their CI build fails. (Maybe look at https://github.com/apps/ci-reporter).

Have Oppiabot notify contributors whenever their title does not follow one of the following patterns:

• Fix #123: ...
• Fix part of #123: ...

Oppiabot should be more explicit in it's comment on PRs made from test, develop or release branches.
oppia/oppia#9513 (comment)

A bot similar to this: https://github.com/koddsson/eslint-disable-probot can be implemented by changing the eslint-disable pragma to pylint-disable pragma.

This check is not fool-proof since it works on the patch attribute of the file object which remains undefined for large files (due to limitations of the GitHub API).

Notify @vojtechjelinek on PRs with slow last-updated checks.

Update the versions of all the oppiabot dependencies, to keep them recent. This might help with the timeouts issue #136

The aim of this issue is to fix a typo with Oppiabot -- in particular, adding a space after the username in the "Assigning @dchen97to add the required label" section.

As an example, please see:

oppia/oppia#10999 (comment)

For every PR which has been open for > 72 hours, work from the most recent comment backwards to identify the last “streak” of review comments by the author of the PR. (If the last comment isn’t by the author of the PR, skip this PR. Also ignore any comments by codecov or oppiabot.) Then, see if this last streak of comments includes the string “PTAL”. If more than 72 hours has elapsed from the “PTAL” comment, then assign oppia-dev to the task. This is recorded in metrics and the reviewer is pinged. This needs to be checked on a daily basis

Oppiabot's "new owners" message is confusing, see: oppia/oppia#11084 (comment). Specifically:

1. It's copying unrelated things from the owners file (comments)
2. Why does Vinita care about this? Just because she's the initial reviewer? Sandeep actually has to approve the change, so it seems more relevant to him as the codeowner of the changed file.

See https://developer.github.com/changes/2020-04-15-replacing-the-installation-and-installation-repositories-events/ for context. There will be a brownout on September 1 for these events, and on October 1 they will stop working.

Oppiabot should check that whenever package.json is changed, yarn.lock must be accompanied (but not vice versa).

Refer: oppia/oppia#8931 (comment)

The bot should assign the code-owners for review once the project owner adds the “Need code owners approval” label. It should also leave a message saying “Assigning to @XXX for ABC file, @YYY for DEF file and @ZZZ for GHI file for code owner review.”

Currently, oppiabot responds to all PRs created in the oppia repository.
We need to modify the functionality such that it does not respond to PRs created by bots like the translate wiki.

Since probot scheduler is being archived, we need to move the periodic checks to Github actions.
Github actions allow us to set up a cron job as part of the jobs needed for the action. But to enable the action to be able to comment on pull requests, we need to authenticate as oppiabot.

See probot/probot#1370 (comment) for more information.