Add example udd.yaml for GitHub actions to automate pull-request about deno-udd HOT 7 CLOSED

closing with #40.

https://github.com/hayd/deno-udd#scheduled-github-action

from deno-udd.

If you re-run when other PR is opened it will just create a new one.

About, $(find . -name ".ts"), it is useful, so it can be an option, but I don't think it should be the default entry point.

What should I use instead of 0 0 then?

Thanks!

from deno-udd.

What should I use instead of 0 0 then?

Hmm, I can't actually find the reference, I was sure GitHub had mentioned this in their initial annoucement of scheduled actions - perhaps it's no longer the case. The idea was that everyone shouldn't schedule their actions at the same time (which 0 0 is the obvious example), so as not to pressure GitHub and whatever services you are calling (in this case the deno cdns), it's better to spread the load across the day.

If you re-run when other PR is opened it will just create a new one.

In the action-behaviour it doesn't actually include this case, but in the concepts diagram it suggests changes can be "force pushed to update" the branch - this makes sense in the case your explicitly name the branch.

I guess there's another interesting question here: if the tests fail what is the desired behaviour.

1. silently doesn't update (I am guessing this is what happens atm, although Github may notify you of failed CI runs)
2. create PR but it fails CI (provided you also have CI!) and requires human fixing (e.g. over breaking API changes).

I suspect 2. is preferable, which is to say, it's tempting to drop the --test .

Thanks again for this yml.

from deno-udd.

Hmm, I can't actually find the reference, I was sure GitHub had mentioned this in their initial annoucement of scheduled actions - perhaps it's no longer the case. The idea was that everyone shouldn't schedule their actions at the same time (which 0 0 is the obvious example), so as not to pressure GitHub and whatever services you are calling (in this case the deno cdns), it's better to spread the load across the day.

It makes sense, in this case the time it happens is not very important so I could change it.

In the action-behaviour it doesn't actually include this case, but in the concepts diagram it suggests changes can be "force pushed to update" the branch - this makes sense in the case your explicitly name the branch.

I think this would be the best.

I suspect 2. is preferable, which is to say, it's tempting to drop the --test .

I'm not sure about this, I prefer to have the ci and udd separated.

The CI runs every time I push changes, I need it to finish as quickly as possible, to see if all my changes are correct and continue with new features.

Whereas UDD I prefer that I run only once a day, preferably while I am not developing.

It seems to me that the best thing would be for --test to remain and that if the PR fails, that a new pull request will still be opened and then I or some other contributor will fix everything in the same PR.

from deno-udd.

I think we're not quite following each other/getting wires crossed RE the --test thing, hopefully code explains:

I updated to https://github.com/hayd/deno-udd/blob/ab0112ff1c756e8c812e0e67dace39cb52fbc00e/.github/workflows/udd.yml

#39 is working PR example, if we leave open a week then we should see it work over a new std release (but I am already convinced that it is working). Once that's merged I'll include mention of this (and your contribution) in the README. Thanks again!

from deno-udd.

I think we're not quite following each other/getting wires crossed RE the --test thing, hopefully code explains:

I updated to https://github.com/hayd/deno-udd/blob/ab0112ff1c756e8c812e0e67dace39cb52fbc00e/.github/workflows/udd.yml

I understand you now.

Once that's merged I'll include mention of this (and your contribution) in the README. Thanks again!

Thanks!

from deno-udd.

Nice

from deno-udd.