-
Notifications
You must be signed in to change notification settings - Fork 169
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
Disable workflows for a forked repository #1932
base: main
Are you sure you want to change the base?
Conversation
8759646
to
058f985
Compare
Adding a check for the trigger in CLA job. |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
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, Sachin. This looks interesting. Do we need all of these to be disabled or just the ones that automatically run on a schedule? Also, I know I sometimes run the integration_tests.yml from my account, and I'd like to be able to continue to do that as needed. Is there any way to only disable the scheduled runs in forks and retain the ability to run them on demand?
Thanks Ben for reviewing this PR. Here are the scheduled workflows clean_up Here are the ones which run on a PR in local repository (as can be seen from this PR) CLA bot
Just to be on the safer side, thought of disabling all. In case, if some tests later get added in the schedule workflows list.
Yes, there is a way to run any tests in the local PR by removing the condition for forked repo. |
097a8f2
to
3272158
Compare
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
bd2ac6c
to
d4d97c3
Compare
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
Maybe I'm in the minority here, but I'd still like to be able to manually run the nightly integration tests from my repo (screenshot below) without having to make my main branch diverge from the upstream main branch by committing a change to revert integration_tests.yml back to how it is right now. Would it be possible to retain this capability by adding structuring the
I believe this would only need to be done for the ones that have this:
We should also get @bettinaheim to weigh in here. |
c38c280
to
a716073
Compare
Does this check prevent manually running the yml file? The original issue was logged because these scripts are "on by default". So if you have a fork, you have to go through them all one by one and disable them, or set up email filters to send all the failures to your deleted folder or both. For a fork, these scripts should all be "off by default" since many/most won't have access to the runners, etc. anyway. |
Perhaps relevant: https://github.com/orgs/community/discussions/26704#discussioncomment-5268498 That thread makes it look like users have to manually accept workflows for new forks, at least as of March 2023. |
FWIW, I picked 3 random forks that were opened in the last few months, and they all contain 0 Actions runs:
So maybe GitHub's changes supersede the need for this change? |
CUDA Quantum Docs Bot: A preview of the documentation can be found here. |
@bmhowe23 Should I proceed with the changes as per the suggestions made here? |
Perhaps we should discuss at the team meeting. I think that the original issue (#1852) isn't relevant anymore due to GitHub's changes mentioned above. For example, the 3 freshly forked repos I mentioned above have 0 Actions runs, so it seems like the underlying issue won't appear for any new forks. |
This is @bettinaheim comment on this PR "A repository can always disable workflows in the GUI: |
For issue #1852 raised by @schweitzpgi
Test (PR on a forked repository)