[ANN] The TagBot GitHub App is deprecated in favour of the TagBot GitHub Action

mauro3 · February 8, 2020, 9:31pm

Should I uninstall the old TabBot App once all the Action PR are merged?

dlfivefifty · February 8, 2020, 10:16pm

I’m seeing the same thing. Here’s a link to an example error: https://github.com/JuliaApproximation/ApproxFunIntrospect.jl/commit/66e666b25f043f991c2a223bd099c3bd1e4cc422/checks?check_suite_id=446140216

dilumaluthge · February 8, 2020, 10:39pm

Alright @dlfivefifty @rdeits the error seems to arise if your repository does not have a Project.toml file.

The two solutions are:

Add a Project.toml file to your repository.
Delete the .github/workflows/TagBot.yml file from your repository.

dlfivefifty · February 8, 2020, 10:49pm

I think this is clearly a bug In the Action and should be corrected. Mass PRs are generally frowned upon, as it creates undesired work for a lot of people. Adding in extra steps to work around a bug in the PR is a step too far.

dilumaluthge · February 8, 2020, 10:49pm

To be fair, REQUIRE files have been deprecated and discouraged for a long time.

dlfivefifty · February 8, 2020, 10:53pm

Some of the repositories haven’t been touched since Julia v0.5. Don’t put in a PR to a defunct repository that doesn’t take into account it’s not valid on Julia v1.0… It’s equivalent to putting a PR into a Python repository, which also doesn’t have a Project.toml file

christopher-dG · February 9, 2020, 2:08am

Ok, I’ll try to address everything in order:

Yeah I think so. I’m not sure that it handles updates, but it could be made to do so.

This was already discussed, but some additional information: Even if it were in Julia, it’s a Docker image so the Julia download would only be at build time. So users would not download Julia, they would download a Docker image that has Julia preinstalled.

I would have liked to have written it in Julia,.

But I’ll be totally honest: Python is objectively better for this stuff right now. I’m not saying Julia won’t be a better general purpose language one day in the future (I really want it to be!) but changelog template support would be far worse without Jinja, and GPG password support would not exist without python-gnupg. In its current state, TagBot finishes its run before a Julia-implemented TagBot would finish compiling stuff. Obviously performance is less important when it’s running in the background without your knowledge, but hey, with potentially 2000 jobs every hour I think that the energy savings are substantial. I’ve gotta make up for the huge number of CI jobs I triggered yesterday…

Also, my dev experience has been far better. Because the code is basically one giant ball of side effects, testing it is really hard without a good, convenient mocking library and unittest.mock is far ahead of Julia alternatives (I say this as someone who maintains a mocking library!). The test suite with ~100% coverage, static analysis, lint checking, and format checking takes less than 3 seconds. I’d imagine the Julia equivalent to take minutes.

In the future, you probably could rewrite it in Julia and be successful; it’s only ~600 LOC.

This was an oversight by me. I’m sorry. I disabled those emails on my own account a long time ago and I totally forgot that they were a thing.
I also didn’t really expect the PR to be merged by any really old packages that don’t have a Project.toml, and I didn’t explain that thoroughly enough above.
To be clear now: TagBot is only for “modern” packages that want to be registered in a registry. If your package is being developed and registered presently, you should definitely have a Project.toml. If it’s not, you should not bother installing TagBot.
I’ve updated TagBot to no longer error in this case.

You can if you want, it’s a good idea because it immediately revokes my access to your packages through the App. But if you don’t, the App will still not run on your packages because it checks first to see if the Action is set up.

tkf · February 9, 2020, 2:32am

Old TagBot had this list of issue/PR labels for excluding items from the changelog:

When using the automatic changelog, you can ensure that certain issues or pull requests are not included.
These might include usage questions or typo fixes that aren’t worth mentioning.
To exclude an issue or PR, add a label to it with one of the following values:

changelog skip

duplicate

exclude from changelog

invalid

no changelog

question

wont fix

You can spell these in a few different ways.
For example, no changelog could be nochangelog, no-changelog, no_changelog, No Changelog, NoChangelog, No-Changelog, or No_Changelog.

However, IIUC, it looks like the latest TagBot supports only changelog-skip:

github.com

JuliaRegistries/TagBot/blob/v1.5.3/action.yml#L49


      
          [Diff since {{ previous_release }}]({{ compare_url }})
          {% endif %}
          
          {% if custom %}
          {{ custom }}
          {% endif %}
          
          {% if issues %}
          **Closed issues:**
          {% for issue in issues %}
          {% if "changelog-skip" not in issue.labels %}
          - {{ issue.title }} (#{{ issue.number }})
          {% endif %}
          {% endfor %}
          {% endif %}
          
          {% if pulls %}
          **Merged pull requests:**
          {% for pull in pulls %}
          {% if "changelog-skip" not in pull.labels %}
          - {{ pull.title }} (#{{ pull.number }}) (@{{ pull.author.username }})

Can you add back all the previously supported labels?

Edit: posted as an issue Are labels like `no changelog` supported in GitHub Action? · Issue #57 · JuliaRegistries/TagBot · GitHub

staticfloat · February 9, 2020, 8:27am

Just as an aside; we do now have caching infrastructure in place in many cloud hosting providers (including those that GH actions run inside of) that allow us to pay O(1) monthly costs for downloads within those datacenters. If you happen to launch an incredibly popular bot that runs in a new datacenter, we will just add a caching server in that datacenter. So don’t let download cost dissuade you from building cool infrastructure! I do happen to agree with Christopher that Python is a great tool for this purpose though; some pieces of the Julia caching infrastructure are written in Python for exactly these reasons. That decision boundary is moving, but it’s a bit of a slog with a few major technical hurdles in the way.

lostella · February 9, 2020, 1:47pm

So once we merge all PRs, or enable the action manually on all Julia repositories, we can safely revoke the permissions granted on an org to the TagBot app?

Tamas_Papp · February 9, 2020, 1:57pm

I very much appreciate all the work that was put into this, and the help with the transition.

However, having a lot of Julia repositories, this morning I found hundreds of notifications in my mailbox.

I would like to suggest that the next time someone wants to make thousands of automated PRs, they consider

an on-demand option with package-level granularity (type the Github username/repo.jl into a web form, get a PR)
an on-demand option with user-level granularity (all Julia repos for that user/organization get such a PR).

chakravala · February 9, 2020, 2:45pm

Recently the .travis.yml configuration file had deprecating changes, probably a rare occurrence.

Personally, I am choosing not to rely on Github actions, as I don’t want to depend on Github.

But this is not a problem for me, since tagging manually doesn’t bother me.

bjarthur · February 9, 2020, 6:18pm

it’s really unfortunate the github does not permit apps to send notifications to each other. if it did, then JuliaRegistrator could tell TagBot when to run, instead the latter being cron’d.

tim.holy · February 9, 2020, 9:07pm

Couldn’t agree more. Honestly, I can’t imagine it will last this way. inotify got invented because polling is awful. I predict that within 6 months they’ll have fixed this.

christopher-dG · February 10, 2020, 2:29am

Yes you can.

Absolutely, I was actually thinking the same thing for future migrations. Sorry for the inconvenience!

Yeah, this was the original wanted design but it’s not possible right now, probably for security reasons. I hope they’ll figure something out!

c42f · February 10, 2020, 6:46am

I’d prefer to use an ssh deploy key rather than a personal access token, but I’m a bit confused about how and whether this will work. Is the problem that the tagbot action can’t trigger a new build for the tag using the github API? In that case I don’t see how the ssh key can help.

fredrikekre · February 10, 2020, 9:20am

The problem is that GitHub does not allow an action to trigger another action. However, if you as a user (e.g. with SSH key) authorize the push, then the doc-building action will trigger. However, if you are not using a user authorization for pushing the docs, then the gh-pages page build (which is also an action) is not triggered, see GitHub Pages build not triggered with GITHUB_TOKEN · Issue #1177 · JuliaDocs/Documenter.jl · GitHub.

tkf · February 10, 2020, 9:44am

There is a chain of GitHub workflows: TagBot → Documenter → gh-pages. IIUC, SSH key (DOCUMENTER_KEY) is only relevant for Documenter → gh-pages. For TagBot → Documenter, I suppose you need to setup a custom token in TagBot.yml (like this: Use custom token in .github/workflows/TagBot.yml by tkf · Pull Request #13 · JuliaTesting/PerformanceTestTools.jl · GitHub )?

fredrikekre · February 10, 2020, 9:47am

You can use a SSH deploy key for TagBot too (GitHub - JuliaRegistries/TagBot: Creates tags, releases, and changelogs for your Julia packages when they're registered), can even use the same as for Documenter. I think this is a better approach since access tokens are not limited to one repo like SSH keys.

tkf · February 10, 2020, 9:51am

I didn’t know that TagBot supports SSH key. Thanks for the clarification.