CompatHelper workflows disabled after 60 days of inactivity

Tooling
#1

I recently learned that Github disables workflows after 60 days of repo inactivity, from e-mails like

[GitHub] The “CompatHelper” workflow in tpapp/… will be disabled soon

Scheduled workflows are disabled automatically after 60 days of repository inactivity.

For TagBot this is not a problem, but for CompatHelper this kind of defeats the purpose (not all repos need to be updated every 60 days if they work fine, and just need the occasional [compat] bump).

Is there a recommended solution/workaround for this? I can always extend these things manually but that’s a bit tedious.

8 Likes
#2

Got the same information from Github today. Same questions: how to overcome the 60 days manual bump?

#3

Two not at all serious proposals, but maybe someone can spin something useful off of them:

  • Depend on a dummy package that gets bumped every 59 days to trigger CompatHelper?

  • Add another Github workflow that simulates repository activity every 59 days?

#4

It can be automated e.g. via curl from a remote machine via REST API:

An example for my case:
List the actions:

curl -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/oheil/M.jl/actions/workflows

Enable action with action ID 1909026, you need an access token:

curl -u oheil:ACCESS_TOKEN_WITH_ADMIN_RIGHTS -X PUT -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/oheil/M.jl/actions/workflows/1909026/enable

This can be put into a cronjob for example.

I think this is the way which is github canonical.

1 Like
#5

It is in the sense that you’ll need to manually enable it once it’s deactivated. However @christopher-dG is looking into alternatives (not a promise and I believe he’d appreciate help on this!)

2 Likes
#6

Could we make a GitHub action for that? :laughing:

1 Like
#7

Of course.
You need a second, which activates the first, and the first activates the second (and of course TagBot and Compat). With an offset of 30 days to each other this should run forever… and ever… and ever… and ever…

3 Likes
#8

Honestly, the best long-term solution for CompatHelper is for someone to add Julia support to Dependabot (https://github.com/dependabot/dependabot-core).

I don’t have the time to take this on. But if someone else takes the lead, I can probably provide some advice.

3 Likes
#9

I know that at some point, @christopher-dG mentioned interest in this.

If you want to help out with adding Julia support to Dependabot, please reach out to @christopher-dG and myself on Slack or Discourse.

1 Like
#10

Here’s the plan:

This weekend, I’ll have a look at getting the General registry + TagBot to work without the cron trigger (see this issue for more details). I expect to have something working long before the 60 days are up. However, this will require everyone to update their TagBot.yml files to include the new trigger. I won’t be doing any automated PRs this time around.

Dependabot support is a far larger project, but I do still plan on doing it. Given that I have a sort of deadline now, I can hopefully carve out some time to get it done in the next month or so, so that the review/integration process is done by the end of the 60 days. This will effectively deprecate the CompatHelper action; you’ll get automatic PRs from Dependabot provided that you’ve enabled that feature in the GitHub settings.

10 Likes
#11

Hi all, I just realized that compathelper has been disabled for most of my packages since I haven’t touched quite a few of them for a couple months. Is there a solution to this?

1 Like