Add example udd.yaml for GitHub actions to automate pull-request

[hayd]

@UltiRequiem put together this script to automates dependency updates. I think it would be really nice to include/publicize it in the udd repo:

https://github.com/UltiRequiem/deno_template/blob/main/.github/workflows/uud.yaml

name: Dependencies

on:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * *"

jobs:
  udd:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - uses: denoland/setup-deno@v1
      - name: Update dependencies
        run: >
          deno run -A https://deno.land/x/udd/main.ts
          $(find . -name "*.ts") --test="deno test -Ar"
      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v3
        with:
          commit-message: ":arrow_up: Update Dependencies"
          title: Update Deno Dependencies
          body: >
            Dependencies updates using [deno-udd](https://github.com/hayd/deno-udd).
          branch: update-deno-dependencies
          author: GitHub <noreply@github.com>
          delete-branch: true

Questions: What happens if re-run and no merge since PR opened (does it update the PR or create a new one)? Is the $(find . -name "*.ts") reasonable (Should this be better supported in udd itself?) ?

Note: IIRC GitHub recommends not using 0 0 to avoid everyone using 0 0 😆 .

But overall this is really nice, thanks @UltiRequiem!

[UltiRequiem]

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!

[hayd]

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.

[UltiRequiem]

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.

[hayd]

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!

[UltiRequiem]

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!

[hayd]

closing with #40.

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

[UltiRequiem]

Nice