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

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… :upside_down_face:

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.

10 Likes

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:

Can you add back all the previously supported labels?

Edit: posted as an issue https://github.com/JuliaRegistries/TagBot/issues/57

3 Likes

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. :slight_smile:

9 Likes

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?

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

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

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.

1 Like

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.

4 Likes

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.

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!

4 Likes

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.

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 https://github.com/JuliaDocs/Documenter.jl/issues/1177.

3 Likes

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: https://github.com/tkf/PerformanceTestTools.jl/pull/13/commits/f0730c06f4f3f757696581fe53fa5b97b1b0b213 )?

You can use a SSH deploy key for TagBot too (https://github.com/JuliaRegistries/TagBot#ssh-deploy-keys), 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.

1 Like

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

To clarify what was already said, the thing that is incapable of kicking off additional GitHub Actions events is simply the default token provided to GitHub Actions, not GitHub Actions itself. So if you supply your own token, it’ll work fine even though it’s still through the GitHub API. And if you provide an SSH key, TagBot will use that key to push the tag via CLI, so actions get triggered just fine as well.

3 Likes

from what I understand, since my Controlz.jl package is an official package in the Julia registry, then every time I make tag a release on Github, this should update the Julia registry with this new release. Is that right? I made a new release on Github but then the package registry is not updated.

https://github.com/SimonEnsemble/Controlz.jl/releases <- I made two releases
https://github.com/JuliaRegistries/General/tree/master/C/Controlz <-- not updated

No, you’ve got it backwards actually :sweat_smile:
You register your package with Registrator, then when that’s finished doing its thing TagBot will make a GitHub release.

5 Likes

I merged the PR as requested. However, then I got an error email
" Run failed for master (a98aa77)

Repository: ExoJulia/ExoplanetsSysSim.jl
Workflow: TagBot
Duration: 30.0 seconds
Finished: 2020-02-21 09:01:08 UTC

View results

Jobs:

—"

Following that link yield a red X next to " Run JuliaRegistries/TagBot@v1" and some error message from a Python script, maybe related to Docker. I can’t tell if this is expected, something that will fix it self automatically, a problem with your scripts, or the result of some unsatisfied assumption about what my package would provide.

Any hints?
Thanks,
@eford

EDIT: Oh wait, it just fixed itself somehow. Here is the new release that I expected earlier.

HI, I’m getting something similar with Tagbot not creating a new release as expected. Don’t quite know where to ask so will follow here. The main issue seems to be the git fetch is not splicing in a target SHA or something. Here is action workflow output (copying from browser):

Processing version v0.6.0 (d8aa89814f4ee4451491ad9a053782c4945b6670)
fatal: ambiguous argument '': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
##[error]Git command 'git -C /tmp/tagbot_repo_11_28_w8 rev-parse ' failed
Exiting with status 1

I double checked that the tagbot workflow file in the repo is as specified at the top of this Discourse post. A similar process worked on one of my other repo’s a few days ago, so this might be a common problem higher up rather than local repos?

Thanks in advance for any help!

EDIT:

Run JuliaRegistries/TagBot@v1
INPUT_TOKEN -e INPUT_REGISTRY -e INPUT_BRANCHES -e INPUT_DISPATCH -e INPUT_DISPATCH_DELAY -e INPUT_LOOKBACK -e INPUT_SSH -e INPUT_SSH_PASSWORD -e INPUT_GPG -e INPUT_GPG_PASSWORD -e INPUT_CHANGELOG -e INPUT_CHANGELOG_IGNORE -e HOME -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e RUNNER_OS -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e GITHUB_ACTIONS=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/DistributedFactorGraphs.jl/DistributedFactorGraphs.jl":"/github/workspace" degraafc/tagbot:1
Processing version v0.6.0 (d8aa89814f4ee4451491ad9a053782c4945b6670)
Generating changelog for version v0.6.0 (d8aa89814f4ee4451491ad9a053782c4945b6670)
Creating release v0.6.0 at d8aa89814f4ee4451491ad9a053782c4945b6670
Exiting with status 0

The default TagBot.yaml (as written in the first post) is scheduled to run every hour. Can anyone share insights about the resource cost of such a run? So is this just a single http call or is there a more involved machinery in play like e.g. docker container startup etc…?

It should be made more visible what this Tagbot does to allow better informed decision on how to use it. In my use case of a library that changes rarely, the Tagbot is either a resource hog when configured to be run often, or results in a large tagging “latency” in the other case.

Maybe this can be achieved with a simple comment in the TagBot.yaml template above the cron line. e.g: # spin up ubuntu virtual machine and check repository for tag-action every hour. (…or whatever the TagBot actually does).