Skip to content
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

Create Project Automation Shared Workflows #168

Merged

Conversation

jarmak-nv
Copy link
Contributor

@jarmak-nv jarmak-nv commented Jan 4, 2024

Closes #163

This PR creates 5 new reusable workflows, all for project automation tasks.

  • project-get-item-id.yaml

    • All project automation workflows need to call this once, projects use a custom ID for items within them rather than the global node id of the item. This returns the ID needed for downstream automations
  • project-get-set-iteration-field.yaml

    • This finds the current iteration and returns it
    • if UPDATE_ITEM is set to true, it sets the field for the item to the current iteration as well
    • if UPDATE_LINKED_ISSUES is set to true, it also sets the same iteration to linked issues
  • project-get-set-single-select-field.yaml

    • This finds a specific OptionId for a provided single select value and returns it
    • if UPDATE_ITEM is set to true, it sets the field for the item to the given value as well
    • if UPDATE_LINKED_ISSUES is set to true, it also sets the same field to linked issues
  • project-set-text-date-numeric-field.yaml

    • These three all follow similar usage patterns in graphQL so they're combined
    • Currently, these only set values, but if given a necessary usecase we could switch to a get-set as well
    • if UPDATE_LINKED_ISSUES is set to true, it also sets the same field to linked issues
  • project-update-linked-issues.yaml

    • The get-set/set workflows all call this workflow when UPDATE_LINKED_ISSUES is true

These workflows have all been tested:

  • On this PR
  • Successful run link is here
  • Caller Workflow is here
    • You may note how there are hard-coded graphQL IDs for project fields in the caller workflow
      • This is done because otherwise we need to constantly re-query the fields and I want to minimize querying to prevent any possible graphQL API rate limiting against the token. Per GitHub these are static values so we shouldn't get caught out by changing values.

TODO BEFORE MERGE

Currently all of the reusable workflows have the secret set to PROJECT_MANAGEMENT_SECRET, this needs to be changed to ADD_TO_PROJECT_GITHUB_TOKEN which is a token scoped specifically for project-related tasks.

@bdice
Copy link
Contributor

bdice commented Jan 4, 2024

I might be missing something in the terminology here. What is an iteration field?

@jarmak-nv
Copy link
Contributor Author

I might be missing something in the terminology here. What is an iteration field?

Docs on iteration fields

But regardless of docs, the most common iteration field is a sprint field. They can also represent releases, or really any block of time between two dates depending on the level of maintenance people want to apply to the field since in the project you can modify the start/end dates beyond the automatically provided "every X weeks"

Copy link
Member

@ajschmidt8 ajschmidt8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Btw, you can also use the github-script action for making GitHub API calls.

github-script is able to make GraphQL calls and also has the benefit of supporting retries to avoid random transient networking issues:

@ajschmidt8 ajschmidt8 merged commit adaaacd into rapidsai:branch-24.02 Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

GitHub Project Automation Shared Workflows Approach
3 participants