Confusing instructions from JuliaRegistrator

Tooling
1

Hi, this message from JuliaRegistrator is really confusing:

Also, note the warning: Version 0.1.3 skips over 0.1.2
This can be safely ignored. However, if you want to fix this you can do so. Call register() again after making the fix. This will update the Pull request.

Does register() mean @JuliaRegistrator register?

And I can’t very well fix it from the same commit, it needs to be a new one. So I could do this from a different commit. Does that cancel the original request, or would it try to complete both, leading to even weirder ordering of versions?

I’ll just stop it and start again, that’s fine, but it would be nice to update this with something more informative. So mostly this post is just to let you know the wording of this message is very confusing.

1 Like
2

Yep! Looks like the wording needs to be updated.

It makes a new pull request whenever the version in Project.toml changes, otherwise it updates the existing PR. So here the wording is a bit misleading, since updating the version is the one thing that causes it to make a new PR, as far as I know (but it uses the same wording for any auto merge failure). However, since auto merge failed, it won’t try to merge that PR regardless if you make a new one.

It’s definitely helpful to report this stuff here, but since it’s open source and community-maintained, it’s even better to file an issue or PR at GitHub - JuliaRegistries/RegistryCI.jl: Continuous integration (CI) tools for Julia package registries, including registry consistency testing, automatic merging (automerge) of pull requests, and automatic TagBot triggers :smiley:.

1 Like
3

Thanks @ericphanson

Ok, but what does it mean for it to change? Is it “It makes a new pull request if there’s a new commit to Project.toml before registration is complete”? So, JuliaRegistrator watches the whole repo, and not just the commit where it was called?

1 Like
4

Sorry, I wasn’t clear.

I mean if you change the version in the Project.toml then call the registration command again. In other words, whenever you call register, it looks to see if there is already an open PR to General for that version of that package. If there is, it updates that PR with the new registration details (the commit you triggered it on, etc). If not, it makes a new PR to General.

1 Like
5

Ahh, ok. This has bitten me before. Something like

  1. I called @JuliaRegistrator register
  2. I realized there was another change I wanted to make
  3. So I made the change, updated the version, and called @JuliaRegistrator register from the new commit, thinking there would just be a quick succession of releases
  4. It (and I) got confused, because of the behavior you describe.

I guess it’s a kind of race condition, right? I mean, it makes sense once you know how it works, so maybe it’s ok. But it’s a little funny that the end result depends how long it takes the registrator to do its thing.

6

Yeah, that’s true. I think it’s not so easy to fix though.

I think a better rule could be:

At register time, if there is already an open PR for a previous version of the same package, then a new PR should be opened but auto merge should wait for the previous PR to be merged or closed before running (and should say that’s what it’s doing).

One downside of that rule is that this would mean if you accidentally forget to bump the version and register, then a PR gets opened and automerge fails (since the version exists). Then if you fix it by bumping the version and registering again, the new PR would wait for the old one, ie you would need to wait for someone to manually close the old PR.

This could be ameliorated by adding another feature, like the package-registeree can close the PR by commenting “close PR” or something like that.

I think both these features are doable but non-trivial to implement.

2 Likes