[FEA]: Project automation improvements #1093
Assignees
Labels
feature request
New feature or request
Comments
3 tasks
rapids-bot bot
pushed a commit
that referenced
this issue
Sep 8, 2023
Closes #1093 Closes #1109 This PR creates a suite of new GitHub project automations to make our lives easier, and updates the issue templates. For reference on the project automations, please see [CCCL's workflows](https://github.com/NVIDIA/cccl/tree/main/.github/workflows). ## Issue Template Updates ### `bug_report.yml` - Adds K8s as an option in the installation method dropdown per #1109 - Adds some default text to the log outputs and `print_env.sh` output to auto-hide/collapse for easier reading ### `feature_request.yml` - Removes the section on alternative approaches - Nobody used this (internal or external) and I don't think it adds value to have all the extra space. If someone wants to discuss alternatives, there's still the "misc" box at the end ## Project Automation Updates ### `label_external_issues` I've updated the action to label external issues with both https://github.com/nv-morpheus/Morpheus/labels/external and https://github.com/nv-morpheus/Morpheus/labels/Needs%20Triage. Doing so allows us to remove the https://github.com/nv-morpheus/Morpheus/labels/Needs%20Triage label but still track through Slack integrations on the https://github.com/nv-morpheus/Morpheus/labels/external label. Right now if we want it to continually be integrated in Slack it would need to keep https://github.com/nv-morpheus/Morpheus/labels/Needs%20Triage in perpetuity which is inaccurate and makes the Triage view in the project messy. An issue we've put in the backlog is no longer in need of triage! ### `project_automation_set_in_progress` This action runs when a PR is opened, converted to a draft, or a review requests changes. It: - Sets the PR to a draft if changes are requested by the review - Sets the PR and linked issues to In Progress - Except in the case of a PR being opened as not a draft, then we set these to In Review - Checks if there's a Start Sprint, if not, it sets it to the current Start Sprint - Sets the Working Sprint to the current Working Sprint ### `project_automation_set_in_review` This action runs when a PR is marked Ready for Review - promoting from a draft triggers this action. It: - Sets the PR and linked issues to In Review ### `project_automation_synchronize_issues` This action runs when a PR is edited, we're interested here because we should be editing in closing keywords for issues if new or old issues are realized to be closed by this PR. It: - Finds the current Status Start Sprint and End Sprint from the PR - Sets all linked issues to the same values ### `project_automation_set_roadmap` This action runs on PR or Issue close. It: - Sets the Issue/PR roadmap field to the current roadmap - Technically, it sets it to the top value in the Roadmap dropdown, so we just need to continue to be diligent in updating that on release ### `project_automation_track_pr_dates` This action runs on PR open/close/ready for review. It: - Sets the Start Date/Review Start Date/End Date field for the PR in the project. This way we never need to touch it, but we can get an idea of how long PRs are in the review stage, or how long in general it takes for one to get opened and then moved into a ready for review state. When it can, it uses dates in the PR metadata, but a GHA doesn't actually have a date associated with it so we use opened/closed dates. For review, we format the date in a little shell command and store it in an environment variable, in EST. Authors: - Ben Jarmak (https://github.com/jarmak-nv) Approvers: - Michael Demoret (https://github.com/mdemoret-nv) URL: #1168
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is this a new feature, an improvement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
Right now things like syncing status between issues and PRs is a totally manual process which can get missed. When issues and their PRs get out of sync it can provide confusion between customers, and other stakeholders and the engineering team so it's important to keep them in sync.
Describe your ideal solution
GitHub actions can be written to automatically manage the status field and keep them in sync.
See NVIDIA/cccl#170
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: