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.
Releases · SimonEnsemble/Controlz.jl · GitHub ← I made two releases
General/C/Controlz at master · JuliaRegistries/General · GitHub ← not updated
No, you’ve got it backwards actually 
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
Jobs:
- 2ff342d3-b786-5c12-861a-919288c85c4f failed (0 annotations)
—"
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).
My bad guys! I pushed a new version but forgot one step of the release process. I’m working on setting up automatic error reporting without actually failing the action so you aren’t notified of this stuff in the future, as well as a more reliable, automated release process.
TagBot runs in a Docker container, so yes, there is some overhead. Usually it’ll run for ~30 seconds including all that overhead. I think it’s pretty reasonable for people to reduce the frequency to once a day.
2 Likes
I’m getting spammed by messages of the form
Run failed for master (3ddf6fa)
Repository: JuliaSmoothOptimizers/PROPACK.jl
Workflow: TagBot
Duration: 0.0 seconds
Finished: 2020-04-23 16:05:52 UTC
View results
Jobs:
Is there anything to do about them? The message says nothing about what failed or why. How do I make them stop?
3 Likes
I don’t know if it’s related, but today GitHub had issues (again): GitHub Status - Incident on 2020-04-23 13:20 UTC. Also, I’d suggest to reduce the frequency of TagBot to once per day (maybe at a time different from midnight UTC)
1 Like
I have also been getting several emails about TagBot runs failing.
1 Like
I think you opt out of email notifications
Yeah GH has been truly awful for this as of late… I also recommend to reduce the frequency to once daily.
What I really want is to not have to use the cron trigger and have something that reacts to the registry… AKA the old GitHub App Despite the benefits of using Actions, sometimes I regret switching over when stuff like this happens.
2 Likes
What if JuliaRegistrator commented back in the package repo after the new version PR was merged in the General registry? Could you then trigger the workflow based on that comment?
This has been discussed here. I definitely support that strategy but some other concerns were raised.
Unrelated, but I’ve been considering creating a new TagBot as an OAuth application that supports a whole bunch of languages/package registries… Maybe one day I’ll get acquired by GitHub like Dependabot did
5 Likes