Received an inactivity reminder on an actively maintained repo

[loneil]

Describe the issue
On our repo we received and automated repo-mountie issue
bcgov/vue-scaffold#22

But that repository has recent activity, a PR from 6 days before the issue creation as the most recent
See commit history: https://github.com/bcgov/vue-scaffold/commits/master

Additional context
Our workflow for our repos is for the team to do personal forks, create PRs from those forks back to the main repo, and merge. So not sure if that fork->PR pattern is not getting registered as active commits or something. But we haven't seen the repo-mountie issue on other repos yet.
I can't think of anything else that might be different about this repo.

Definition of done

[swcurran]

+1 on this issue. I was just coming in to report the same issue. Looks like PRs being created and merged are not being counted as an "activities" -- they should be.

repomountie is a great tool and I definitely want to see it continue. It does need to continue to evolve as it generates work for many teams. By putting resources into improving the accuracy of the service, you reduce the resources needed by teams across government.

Thanks!

[boshek]

Another +1 on this issue. I have received a stale repo notification here with a repo that had commits very recently.

[jujaga]

Another +1. Recently got another repo-mountie alert saying it's been 180+ days on the following places:

• It's Been a While Since This Repository has Been Updated nr-get-token#339
• It's Been a While Since This Repository has Been Updated alpine-node-libreoffice#5
• It's Been a While Since This Repository has Been Updated common-hosted-email-service#110
• It's Been a While Since This Repository has Been Updated nr-showcase-devops-tools#23

All these repos have had commits to them less than 180 days ago.

[cmhodgson]

Just wanted to bump this issue as it continues to be a problem.

[stephhazlitt]

+1 for this issue (just got an inactivity issue from {repomountie} for a repo that had a merged PR last month). Given the issue was first raised over a year ago, I am wondering if we can consider turning this functionality off until it can be fixed?

[mishraomp]

another +1 on this one

[TayGov]

another +1 there are multiple repos that are active and receiving these. The issue appears to be the date that is being used to trigger. It is using updated_at:

UPDATE: the behavior described below wasn't intended. pushed_at will be updated any time a commit is pushed to any of the repository's branches. updated_at will be updated any time the repository object is updated, e.g. when the description or the primary language of the repository is updated. It's not necessary that a push will update the updated_at attribute -- that will only happen if a push triggers an update to the repository object. For example, if the primary language of the repository was Python, and then you pushed lots of JavaScript code -- that might change the primary language to JavaScript, which updates the repository object's language attribute and in turn updates the updated_at attribute. Previously, the primary language was getting updated after every push, even if it didn't change (which wasn't intended), so it triggered an update to updated_at. (stackoverflow)

Probably should be using pushed_at. In the one of the repos triggered the Github api returns this for the dates:
"created_at": "2020-06-05T17:42:12Z",
"updated_at": "2023-01-31T18:15:44Z",
"pushed_at": "2023-08-14T05:55:19Z",