Spaces:

not-lain

/

omar

like 0

Sleeping

This PR enables Space CI on your Space. Gradio Space CI is a tool to create ephemeral Spaces for each PR opened on your Space repo. The goal is to improve developer experience by making the review process as lean as possible.

⚙️ How it works:

• Listens to pull requests events:
  • If PR is opened => starts an ephemeral Space
  • If PR is updated => updates the Space
  • If PR is closed => deleted the Space
• Checks PR author:
  • If trusted author => ephemeral Space is configured with variables, secrets and hardware.
  • If not a trusted author => ephemeral Space is started without configuration.
  • Space owners are trusted by default. Additional "trusted authors" can be configuration manually.

⚠️ Before merging:

1. Check that the configuration is correct. By default the Space is configured to run ephemeral Spaces on a (free) CPU instance without any secrets.
2. You must set HF_TOKEN as a secret in your Space settings. Token must have 'write' permission. You can create a new one in your User settings.

This is an automated PR created with https://huggingface.co/spaces/Wauplin/gradio-space-ci.
For more details about Space CI, checkout [this page]](https://huggingface.co/spaces/Wauplin/gradio-space-ci/blob/main/README.md).
If you find any issues, please report here: https://huggingface.co/spaces/Wauplin/gradio-space-ci/discussions

Feel free to ignore this PR.

Let me know if you have any feedback on this @not-lain ! It is still an experimental tool :)

@Wauplin

• i loved it, it's also quite easy to setup, and it really does what i want 🚀
• i don't think the secrets should be put in the readme, even tho i don't know what it does, but we should avoid that.
• now something that i didn't try yet is this (would love to see if works or not), let's say someone added a pr and they are not in the trusted list, and then i add them to the trusted list, will that deploy their pr, and what if they made multiple prs, would this deploy all of their prs ?

for this i suggest the owner would make a command in that single pr and use /deploy or some other command to deploy that single pr, if this is feasible it would be quite an interesting addition, what do you think ?

Thanks for the feedback @not-lain ! Glad you liked it :)

i don't think the secrets should be put in the readme, even tho i don't know what it does, but we should avoid that.

For clarification, we expect secret keys to be set in the README, not secret values. So it's not a security breach at that point. Secret keys are public anyway (for example, go to a Space with secret, click on "duplicate Space" and you'll see the secret values you need to set). In the configuration I want users to explicitly write which secrets should be copied over to the CI Spaces as I want the users to be responsible of it, depending on the criticality of their app secrets.
So I do think that have secrets keys in the README is fine.

now something that i didn't try yet is this (would love to see if works or not), let's say someone added a pr and they are not in the trusted list, and then i add them to the trusted list, will that deploy their pr, and what if they made multiple prs, would this deploy all of their prs ?

If you update the trusted list, it will scan through all PRs and (re-)deploy the ones that needs to be deployed. So yes, adding an author to the trusted list is generic to all current and future PRs of that author.

For context, PRs opened by "untrusted" authors (i.e. not by you and not by a trusted author) will still trigger a deployment. The only difference is that secrets will not be set + no special hardware/storage will be attached to the CI Space. So you don't really have to make comment a /deploy command for untrusted authors. What you should do it go to the CI Space that got deployed and set the secrets/hardware by yourself. We could imagine a /trust_this_PR command you could comment but haven't implemented it. Would you use such a command or it is a bit too niche yet?

Overall, difference between trusted and untrusted authors is only about secrets/hardware/storage => the rest of the workflow is the same.

@Wauplin

I want users to explicitly write which secrets should be copied over to the CI Spaces

that's smart, approved ✅✅✅✅

We could imagine a /trust_this_PR command you could comment but haven't implemented it. Would you use such a command

yesss, I would use it 💯

yesss, I would use it 💯

Would you mind opening a feature request on https://huggingface.co/spaces/Wauplin/gradio-space-ci/discussions? :) (or even better, a PR :D)

@Wauplin on it 🫡🫡