-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scheduled Workflow to Fetch PRs Based on Status and Age #28718
Comments
@victoralfaro-dotcms
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 issue_on-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 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. |
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:
Acceptance Criteria
dotCMS Version
master
Proposed Objective
Integrations
Proposed Priority
Priority 2 - Important
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
Assumptions & Initiation Needs
Quality Assurance Notes & Workarounds
Sub-Tasks & Estimates
Total Estimate: 23 hours
The text was updated successfully, but these errors were encountered: