-
Notifications
You must be signed in to change notification settings - Fork 126
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
fix 2 for xlink local cmake #301
fix 2 for xlink local cmake #301
Conversation
- fixes luxonis#272 - replaces PR luxonis#298
Its been lately bumped to require explicit approval - because of HIL testing is being added. Not sure if possible to limit to specific workflows though (as suggested by warning message). That would be better, to still run CI for parts that can be done by public GH runners. Currently there aren't great options in this regard apart from fork solution (that has to be manually updated to keep up to date...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I'm a gihub actions novice. Could you have a workflow yaml specifically for PRs to develop... on:
pull_request:
branches:
- develop
runs-on: [win, linux, x64, gpu] // but don't list self-hosted because all self-hosted runners have the or somehow make workflows that use self-hosted runners need write permissions? because, by default, the github permission token for PRs has only read permission? |
Right now it seems like the approval is a repository wide setting so it determines behavior for all workflows. Right now the explicit approval covers both so as long as we get to PRs in time to check and run the workflow it'll do for the initial HIL testing iteration IMO. Major problem with self hosted runner is that even GH didn't yet decide upon a good means of "security" regarding what/who can run on them, etc.. so they straight up recommend not using them in a public repository. For a repo which deals with HW, this isn't the best solution hah |
Got it. I was looking around (as I might setup workflows myself). I might investigate something like the far under to trigger a specific workflow based on a specific review comment... The auto CI can keep your team busy elsewhere while people like me submit a well-intending PR, but missed something (like I must have in my first PR) in our self-test matrix (or don't have the capability for a broad CI matrix). I get your team is evolving, no worries. 👍 # not syntatically correct...
on:
pull_request_review_comment:
branches:
- develop
if: contains(event.comment, '#do-hil') && event.sender.type = 'Collaborator'
runs-on: [lux_hardware]
steps: ... |
cmake install
(only static issue?) #272I ran four sets of tests -- the 2x2 matrix of
And for each test, I verified:
config works
build works
install works
app build works
app works
These tests were run on Windows 10 with VS2019.
@themarpe , I now realize that the CI didn't automatically run when I opened my last PR -- so I didn't get feedback of CI failure so I could fix the issue. CI didn't run until you triggered something.
Is this your team's policy? Or a config issue that my PR was based to
develop
? As a contributor sample set of 1 😉 it is useful for the CI to give me feedback on my PR so I can fix issues before your team engages.