Scheduled Workflow to Fetch PRs Based on Status and Age

[victoralfaro-dotcms]

User Story

As a dev-ops engineer, I want to create a GitHub workflow with scheduled execution to fetch (from GitHub API) the list of:

• Ready to review PRs that have sat for more than one week without merge.
• Draft PRs that have been in draft status for more than 2 weeks since creation.

Acceptance Criteria

• A GitHub workflow is created with scheduled execution (e.g., daily).
• The workflow fetches the list of ready to review PRs that have sat for more than one week without merge.
• The workflow fetches the list of draft PRs that have been in draft status for more than 2 weeks since creation.
• The fetched lists are logged and optionally notified via a specified channel (e.g., Slack or email).

dotCMS Version

master

Proposed Objective

Integrations

Proposed Priority

Priority 2 - Important

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

• Slack Conversation: [link]
• Support Ticket: [link]
• GitHub API Documentation: [link]

Assumptions & Initiation Needs

• Access to the GitHub repository and API.
• Appropriate permissions to set up and execute GitHub workflows.
• Configuration for notifications (e.g., Slack or email).

Quality Assurance Notes & Workarounds

• Verify that the workflow runs on the specified schedule.
• Ensure that the correct PRs are fetched based on their status and age.
• Test notification delivery and content accuracy.
• Perform regression testing to ensure no interference with other workflows.

Sub-Tasks & Estimates

1. Review GitHub API for fetching PR details (3 hours)
2. Set up a new GitHub workflow with scheduled execution (3 hours)
3. Implement logic to fetch ready to review PRs over one week old (4 hours)
4. Implement logic to fetch draft PRs over two weeks old (4 hours)
5. Test the workflow in a development environment (3 hours)
6. Configure and test notifications (2 hours)
7. Update documentation to reflect the new workflow (1 hour)
8. Deploy the workflow to the production environment (1 hour)
9. Perform post-deployment verification (2 hours)

Total Estimate: 23 hours

[spbolton]

@victoralfaro-dotcms I missed this workflow going in. I have a couple of comments although not a blocker.

1. The naming is not quite following the convention correctly. This is prefixed for cicd, this prefix is reserved for the core workflow actions moving code through the levels of testing and deployment. This workflow is related to general management of Github projects. It is more related to the workflows using the issue prefix although I understand being PR related it is overloading that term, could use pr_ instead.

Note on this, not urgent to modify now but we could refactor later, I would prefer that we group tasks in workflows based upon the trigger and type so we do not have a proliferation of workflows and we can see how they work together. I would categorize this as daily project tasks with this check on open prs as a step in this, if the step is something to be reused it could be a separate action. There is a benefit to the modularisation of having a separate workflow but treating and grouping the level of modularity at the level of the handling of the trigger and type ensures that we can see the work in context of all the things we need to do and also cleans up workflow logging. I would probably choose a workflow of project_daily.yml and put anything in there we need to do based upon the project, pr, issue state on a daily basis.

We do have other workflows not following this model correctly e.g. the following although using the prefix issueon-change which is good, it maybe these could be put under a project top level to group this with actions that may be triggered on pr changes for example. Note that we could actually group these two workflows as just project_issue_on-change.yml. even though assign-issues-to-qa-project should only be triggered on label change, we are already calling issue_on-change_post-issue-edited on labeled instead, it is easy to just have the assign-issues-to-qa-project steps to just be skipped if the trigger was not labeled. Without grouping every change to an issue can trigger multiple workflows to kick off simultaneously

.github/workflows/issue_on-change_assign-issues-to-qa-project.yml .github/workflows/issue_on-change_post-issue-edited.yml

Note: I am not to concerned about urgently fixing up these workflows to follow the pattern if we are going to move to use the GithubApp as these workflows are great candidates to be handled within the app and then removed as independent workflows run by github actions. Changing these to group them better would provide a little more clarity on what the GithubApp should be doing when we move over.