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

Execute workloads based on labels instead of flags in PR titles #366

Closed
wants to merge 56 commits into from

Conversation

vincepnguyen
Copy link
Collaborator

What this PR does / why we need it:
Currently, certain workflows are being skipped/executed based on flags set in PR titles. For example, adding [SAME VERSION] to a PR title prevents the version check workflow from running. However, after adding a flag to a title, checks cannot simply be re-run, since they refer to the state of the PR of the last commit. Resultingly, another commit must be pushed to the PR in order for checks to properly register the PR title change (and therefore flag). Running workflows based on labels instead of flags may remove this issue of pushing new commits. This change enables running build/version check based on labels.

Special notes for your reviewer:

If applicable:

  • this PR has an associated PR with documentation in akri-docs
  • this PR contains unit tests
  • added code adheres to standard Rust formatting (cargo fmt)
  • code builds properly (cargo build)
  • code is free of common mistakes (cargo clippy)
  • all Akri tests succeed (cargo test)
  • inline documentation builds (cargo doc)
  • version has been updated appropriately (./version.sh)

kate-goldenring and others added 9 commits August 12, 2021 12:28
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
@kate-goldenring
Copy link
Contributor

We should update our documentation to reflect that we are now using labels. A PR should go into the akri-docs repo and merge right after this one. @vincepnguyen would you be interested in updating the docs?

@kate-goldenring
Copy link
Contributor

Can you also update the [PR template(https://raw.githubusercontent.com/deislabs/akri/main/.github/pull_request_template.md) to specify using a label instead. I linked it in raw mode so you can see the hidden MD comment that needs to be updated

@@ -10,6 +10,7 @@ on:
- build/intermediate-containers.mk
- Makefile
pull_request:
types: [assigned, opened, synchronize, reopened, labeled, unlabeled]
Copy link
Contributor

Choose a reason for hiding this comment

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

curious - what is synchronize?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

hey Roaa, synchronize is when a commit is pushed to the PR. I found some more details here https://frontside.com/blog/2020-05-26-github-actions-pull_request/

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we want the workflow to run whenever someone is assigned to the PR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good point! I removed the assigned.

Copy link
Contributor

@romoh romoh left a comment

Choose a reason for hiding this comment

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

I think we should be explicit about what the labels mean, so that any contributor can easily interpret them.
"allow intermediate build" and "ignore intermediate build" are very vague. I don't expect others to understand what they mean until they look at the makefile.
How about "use-docker-cache" or "no-docker-cache"?

Is there a way we can only have one label? Default can be docker cache is used, anyone sending a PR touching those special files will re-build the images unless the user explicitly add "no-docker-cache". We don't expect those files to change frequently, right?

[SAME VERSION] Workflow to mark inactive issues/PRs as stale and eventually close them
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
@bfjelds
Copy link
Collaborator

bfjelds commented Aug 27, 2021

How about "use-docker-cache" or "no-docker-cache"?

i'm not sure that these are quite right for me ... the flag controls whether this pr actually builds the intermediate containers (crossbuild, opencv), not whether we use caches. for example, the rust containers (controller, agent, etc) will always use the docker cache and these flags don't impact that.

Is there a way we can only have one label? Default can be docker cache is used, anyone sending a PR touching those special files will re-build the images unless the user explicitly add "no-docker-cache". We don't expect those files to change frequently, right?

we can certainly do what you suggest. i prefer 2 flags and people making an assertive choice because with your suggestion, it is easier for us to burn cpu cycles unintentionally. that probably isn't a huge deal as long as the cpu cycles are unlimited and free, and no one is in a hurry to merge a PR that touches Makefile.

@vincepnguyen vincepnguyen changed the title Execute workloads based on labels instead of flags in PR titles- Execute workloads based on labels instead of flags in PR titles Nov 19, 2021
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
@kate-goldenring
Copy link
Contributor

@vincepnguyen looks like you've been cranking out a lot of changes. Give us a bump when this is ready for another look through.

@vincepnguyen
Copy link
Collaborator Author

/add-same-version-label

@vincepnguyen
Copy link
Collaborator Author

/add-build-dependency-containers-label

@vincepnguyen
Copy link
Collaborator Author

@bfjelds @kate-goldenring @romoh hey everyone, this PR is ready for review :)

@kate-goldenring
Copy link
Contributor

@vincepnguyen can you sign your commits so as to make the DCO pass? More information here.

issue_number: context.payload.pull_request.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: 'Hi there, this change should run a build dependency containers, but running it will take hours. Do you want to run it? If so, please add label "build dependency containers" by commenting "/add-build-dependency-containers-label".'
Copy link
Contributor

Choose a reason for hiding this comment

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

Just curious, why did you choose to have a preceding backslash in "/add-build-dependency-containers-label"

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: remove "a" in "should run a build dependency containers"

Copy link
Contributor

Choose a reason for hiding this comment

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

also clarification: they can also use the normal GitHub UI to add the label right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

can everyone use our labels through the ui or just our admins?

- if: >-
startsWith(github.event_name, 'pull_request') &&
!contains(github.event.pull_request.title, '[SAME VERSION]') &&
!contains(github.event.commits[0].message, '[SAME VERSION]')
contains(github.event.pull_request.labels.*.name, 'same version') == false
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe keep !contains(...) instead of == false


add-label-missing-comment:
runs-on: ubuntu-latest
if: github.event_name == 'pull_request' && (github.event.action == 'opened' || github.event.action == 'unlabeled') && contains(github.event.pull_request.labels.*.name, 'build dependency containers') == false
Copy link
Contributor

Choose a reason for hiding this comment

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

What is this github.event.action == 'unlabeled' trying to capture? What if there is some other label like bug or documentation on the PR? Seems like just the opened expression is sufficient.

@kate-goldenring
Copy link
Contributor

kate-goldenring commented Nov 22, 2021

This is looking great

@bfjelds @kate-goldenring @romoh hey everyone, this PR is ready for review :)

@vincepnguyen this is looking great! Thanks for adding to auto labeling feature! Just had some nits and clarifying questions

Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>

Signed-off-by: vincepnguyen <70007233+vincepnguyen@users.noreply.github.com>
@vincepnguyen vincepnguyen force-pushed the user/vinguyen/buildbylabel branch 2 times, most recently from d30b770 to 48c5ed1 Compare November 23, 2021 00:46
@vincepnguyen
Copy link
Collaborator Author

Some command to rebase and sign off messed up previous commits so I am going to abandon this PR and create a fresh new one and resolve your comments there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Execute workloads based on labels instead of flags in PR titles
6 participants