Hi all, remember when I said that you’d never have to do any maintenance on your TagBot.yml files?
I lied, I’m sorry.
GitHub has started automatically disabling Actions workflows that run on a schedule for repositories that have not seen any activity for 60 days.
To quote the docs:
Warning: To prevent unnecessary workflow runs, scheduled workflows may be disabled automatically. When a public repository is forked, scheduled workflows are disabled by default. In a public repository, scheduled workflows are automatically disabled when no repository activity has occurred in 60 days.
That means that if you don’t touch a repo for 2 months, the scheduled workflows such as TagBot or CompatHelper will no longer run even after you come back to it, unless you re-enable them manually.
To avoid this problem for TagBot, we are switching to a new method that does not rely on scheduled workflows, and instead triggers TagBot on demand. This means that TagBot remain enabled on inactive repos, and also that your tags will come much sooner after registration!
What Do I Need To Do?
Probably within the next few days, merged pull requests in the General registry will start to be accompanied by issue comments made on package repositories that have a TagBot workflow file in .github/workflows. The idea is that TagBot will react to these issue comments, so you need to update your workflow file accordingly.
Your TagBot.yml probably looks something like this:
name: TagBot
on:
schedule:
- cron: 0 0 * * *
workflow_dispatch:
jobs:
TagBot:
runs-on: ubuntu-latest
steps:
- uses: JuliaRegistries/TagBot@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
ssh: ${{ secrets.DOCUMENTER_KEY }}
There are two changes to make: one is the on block, and the second is an if condition in the TagBot job. Here are the new contents that will work:
name: TagBot
on:
issue_comment: # THIS BIT IS NEW
types:
- created
workflow_dispatch:
jobs:
TagBot:
# THIS 'if' LINE IS NEW
if: github.event_name == 'workflow_dispatch' || github.actor == 'JuliaTagBot'
# NOTHING BELOW HAS CHANGED
runs-on: ubuntu-latest
steps:
- uses: JuliaRegistries/TagBot@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
ssh: ${{ secrets.DOCUMENTER_KEY }}
As you can see, the schedule trigger has been replaced with the issue_comment trigger, and the TagBot job now only runs when triggered under certain conditions.
TagBot will open an issue and instantly close it, and will add a new comment on that issue for each new version. You can safely unsubscribe from and ignore that issue.
This looks tedious… and for what benefit?
I won’t be rolling out any automated PRs this time around, since that annoyed a lot of people last time (for good reason), and this change is also not strictly necessary. If your repository stays active, the scheduled workflow will never be disabled. But there are two advantages to adopting the new trigger: your tags will be created almost instantly after your registry PRs are merged, and you’ll no longer have hourly/daily TagBot runs that don’t do anything.
If you want to apply this change to a bunch of repos at once, MassInstallAction.jl can help you out.
For custom registry maintainers
If you run a custom registry, you’ll need to add a new Actions workflow to the registry: see here for an example. This workflow is responsible for notifying package repositories about new versions. You’ll need to create a TAGBOT_TOKEN secret on your registry, and it must contain a user’s personal access token, so that it can create issues and comments on repositories other than your registry. Feel free to contact me if you need a hand getting things set up. I also don’t think it works on self-hosted GitHub currently, so definitely let me know if you maintain one of those so I can figure out what’s necessary.
For custom registry users
If you have packages registered in a registry other than General, you’ll need to change one small detail in the if condition. JuliaTagBot will not be the user creating issue comments, so you need to change that username to whatever your registry is using. Your registry maintainers will know what username to use.
What about CompatHelper?
CompatHelper is another scheduled workflow that will soon be disabled on many inactive repos. There’s not really a good fix for that one, so I’ll soon be implementing Dependabot support for Julia. More on that later!
That is all. If you have questions about this whole thing, or if you just want to tell me that I’ve ruined your week, don’t hesitate!
why didn’t they make this a drag & drop situation like Scratch