adding dependabot functionality

[alex-rakowski]

This adds dependabot functionality to check and create PRs for updates in our GitHub actions dependencies. Similar to the vulnerability one was raised in #593 .

We could extend this to check pip packages, but I've left this out as it is a more breaking change.

  - package-ecosystem: "pip" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      interval: "weekly"
      day: "sunday"
      time: "23:00"
    ignore:
      - dependency-name: "tensorflow"
      - dependency-name: "tensorflow-addons"
      

[sezelt]

What would actually break if we were to enable checking of pip dependencies?

[alex-rakowski]

The ones I'd be worried about are, tensorflow/-addons and mp-api. I haven't tested the latest version of mp-api, we might be able to loosen it to just exclude some versions. Or kick the problem down the road and add it to the ignore packages.

…

On Thu, Jan 4, 2024, 10:57 Steve Zeltmann ***@***.***> wrote: What would actually break if we were to enable checking of pip dependencies? — Reply to this email directly, view it on GitHub <#595 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHD22GFJFY56VGXYYO2ONVDYM33QNAVCNFSM6AAAAABBK4MZR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGYYDKOBXHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sezelt]

I guess I'm more asking, what will it actually do in that case? Will it open random PRs? Will it make tests fail? In what way will things actually be "broken?"

[alex-rakowski]

It opens a pr per dependency to upgrade, I think we can set it to group all the upgrades into a single pr, but this isn't the default. I'm not 100% on the behaviour if you decline a pr, and if it will open a pr to bump the version to a previously rejected one the next time it runs or not. E.g. it wants to bump to x to 1.3, we decline, next Sunday it might suggest X to 1.3, or it might wait to bump x to 1.31. None of our actions test functionality, so unless they break the install or import, we'd wouldn't know if they were breaking upgrades.

…

On Thu, Jan 4, 2024, 12:47 Steve Zeltmann ***@***.***> wrote: I guess I'm more asking, what will it actually do in that case? Will it open random PRs? Will it make tests fail? In what way will things actually be "broken?" — Reply to this email directly, view it on GitHub <#595 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHD22GAC7WBH3XV2T2HI7UTYM4IP3AVCNFSM6AAAAABBK4MZR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXG4ZTSOJZGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sezelt]

OK in that case, I suppose we don't want to turn on pip packages. For github actions, will this do anything different than what we already have? There seems to be some default level of checking for actions vulnerabilities, since we got that other PR. Is there some severity setting that might be different?

[alex-rakowski]

The pr we got came from a setting that looks only for vulnerabilities. These prs would keep things up to date, which would help avoid depreciation issues, get speed/feature bumps etc. I've had it running on my fork for a little while and the updates are fairly infrequent and haven't broken anything so far.

…

On Thu, Jan 4, 2024, 13:39 Steve Zeltmann ***@***.***> wrote: OK in that case, I suppose we don't want to turn on pip packages. For github actions, will this do anything different than what we already have? There seems to be some default level of checking for actions vulnerabilities, since we got that other PR. Is there some severity setting that might be different? — Reply to this email directly, view it on GitHub <#595 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHD22GD536LSRDITQUJ7BSLYM4ORZAVCNFSM6AAAAABBK4MZR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXG44TMNRYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[bsavitzky]

Cool! Looks good :)