Allow for .github to be deployed

[dmadisetti]

Currently .github is explicitly not deployed. This makes sense as you can potentially end up with a recursive deployment. But if I want to run checks on my generated branch, then I need .github to be committed. Recursive situations can be guarded against by explicit on definitions

[Rongronggg9]

Facing the same problem. Turning off clean won't help.

[JamesIves]

This makes sense as you can potentially end up with a recursive deployment. But if I want to run checks on my generated branch, then I need .github to be committed.

What are you running checks on? Is there a reason you couldn't just target the generated branch using actions/checkout as a workaround post deployment? Obviously I don't know your use case, but that feels a fair amount cleaner as opposed to having workflow files on a bunch of different branches.

Deploying .github has the potential to impact a large degree of users, so that needs to be highly considered when making a change like this.

[Rongronggg9]

needs to be highly considered when making a change like this.

Why not just add an option, keep the default behavior unchanged, and give the control right to users?

[JamesIves]

I'd still like to learn more about the use case for this as I would be the one maintaining such an option long-term, and it has the potential to add unnecessary complexity.

[Rongronggg9]

Talk is cheap, show you the code.

https://github.com/Rongronggg9/RSSHub/blob/railway-ci/.github/workflows/railway-update.yml

[dmadisetti]

Here's my usecase- I'm using deploy to create a template: https://github.com/dmadisetti/.dots/blob/template/.github/workflows/dots-manager.yml#L27

I'd still like to run actions on the template branch (specially scheduled actions, as it's my primary branch) as well. My work around (this is a little messy, but whatever), is just to have another action that syncs .github.

A bit of a misuse since I know this is targeted towards pages- so I get if this is a WNF