Create issue metrics workflow

[anupdsouza]

What it Does

• Closes Project Issue / PR Metrics #138
• Created issue-metrics file that can be run manually to generate reports of issues and pr's that were opened and closed in the previous week. The workflow will need to be manually triggered, although this can be updated to run automatically as well via cron jobs.

How I Tested

• Enabled the "Issues" tab for my personal repository and created a dummy issue for metric generation
• Executed the issue-metrics workflow. The workflow generates reports as "Issues" which can then be viewed and action can be taken upon.

Notes

• I've added a section in the workflow that generates dates for the previous month. It is commented out for now but it can be uncommented if one wishes to do a monthly report generation instead. The time calculations can be updated to suit one's needs.
• I've also set the 'assignees' value to the repo owner, in this case its you @mikaelacaron. This allows the github bot to automatically assign the report issues to you.
• I've also set the 'labels' value to 'weekly-report', this adds a nice little label against the issue.
• Alternatively, you could just duplicate the workflow file and rename it to monthly-issue-metrics or something with the appropriate values. This way you could decide whether to run the weekly report or monthly report. This is up to your discretion.
• To set up auto trigger via cron jobs, just add the following under workflow_dispatch:

• Cron timing can be updated via cron expressions.

Screenshots

[mikaelacaron]

@anupdsouza I have a few questions just looking over the yml file, I haven't done this before, but just looking at the workflow you've written so far I wanted to clarify some of it, for my understanding

To set up auto trigger via cron jobs, just add the following under workflow_dispatch:

Is it possible for GitHub actions to trigger this, rather than it running as a cron job?

[mikaelacaron]

Do I need to do anything with this? Do I need to create some kind of secret for this to be able to create issues?

[anupdsouza]

Not required, as per Github documentation:

If you want the resulting issue with the metrics in it to appear in a different repository other than the one the workflow file runs in, update the line token: ${{ secrets.GITHUB_TOKEN }} with your own GitHub API token stored as a repository secret.

[mikaelacaron]

Is this used for anything? It looks like it's all commented out?

[anupdsouza]

Not used at the moment. I left it in as a reference if you wanted to update the workflow such that it'd fetch reports for the previous month instead of the previous week.

[mikaelacaron]

Do I need an environment variable of some kind? This looks like it's referencing one?

[anupdsouza]

No, it's defined on line 28.

[anupdsouza]

@anupdsouza I have a few questions just looking over the yml file, I haven't done this before, but just looking at the workflow you've written so far I wanted to clarify some of it, for my understanding

To set up auto trigger via cron jobs, just add the following under workflow_dispatch:

Is it possible for GitHub actions to trigger this, rather than it running as a cron job?

As per Github documentation, the example uses cron job to schedule it to run once a month.

Wait for the action to trigger based on the schedule entry or manually trigger the workflow as shown in the documentation.

I suppose the workflow could be updated to run every time PR's are created or merged by doing something like this:

workflow_dispatch:
  pull_request:
    branches:
      - dev
  push:
    branches:
      - main
      - dev

but that would result in too many reports being generated. That's why I left it to be run manually.