Testing fix for Documenter issue #103

[mikeingold]

I'm taking a swing at fixing #103.

The deployment docs and deploydocs docstring aren't very descriptive on this point, but from looking around at other packages this versions argument seems like it might be needed.

I suspect this won't retroactively include missed versions, though there's a note on this point that suggests a workaround is to git tag old commits with v0.xx.x-anything to re-trigger workflows.

[JoshuaLampert]

I suspect that this will not change anything. versions = ["stable" => "v^", "v#.#", "dev" => "dev"] is simply the default. It is also not necessary in my other repos. What is also a bit annoying is the fact that this is not easy to debug. We always need to merge a PR into main in order to get some feedback whether the attempt worked or didn't.

[JoshuaLampert]

I see that for v0.13.2 there are these create mode ... lines in the logs, see here, while for the v0.13.3 they are missing, see here. This could give us a hint, where things might go wrong.

[JoshuaLampert]

There is also no [new tag] for v0.13.3, see here.

[JoshuaLampert]

Ah, this one looks wrong.

[JoshuaLampert]

Getting closer... Looks like we are not getting into this if branch, but into this one, which should not be the case.

[mikeingold]

I suspect that this will not change anything. versions = ["stable" => "v^", "v#.#", "dev" => "dev"] is simply the default.

Damn. Looks like you're correct.

What is also a bit annoying is the fact that this is not easy to debug. We always need to merge a PR into main in order to get some feedback whether the attempt worked or didn't.

Exactly my feelings, too. Troubleshooting Actions themselves is very frustrating when the existing version of the Action is the one that gets run.

[JoshuaLampert]

I think I found the issue. You seemed to have registered a new version in another commit than the one, where you bumped the version number. Namely here: c5ee557#comments. I think this lead to GITHUB_REF being set wrongly and thus Documenter.jl using the wrong if branch as outlined above.

[JoshuaLampert]

However, I still don't know why it didn't get fixed with the newer versions starting from v0.13.4.

[mikeingold]

Weird. So I bumped the package patch version number in one commit but waited until after the next commit was added to trigger registration, and that somehow broke Documenter moving forward?

[JoshuaLampert]

Maybe, I am not sure TBH.

[JoshuaLampert]

But I do think, it's a problem with GITHUB_REF because we really should go into the build_type === :release branch in order to have the correct subfolder, where the docs are deployed, set in this line.

[JoshuaLampert]

I checked that in other repos in each commit to the main branch, which bumps the version of the package (and also at the same time triggers JuliaRegistrator) GITHUB_REF picks up the correct new tag like it did for v0.13.2 and for every commit, which does not bump the version number GITHUB_REF matches the devbranch. But since v0.13.3 (i.e. also for all other releases after v0.13.3) GITHUB_REF also matches the devbranch for the commits releasing the new version. So I am pretty sure this is the problem. Whether or not this is related to the fact that JuliaRegistrator was triggered for another commit than the version bump commit to v0.13.3, I don't know. I also don't the answer to the most interesting question of how to solve the issue 😅 (but at least I learned a bit about how Documenter.jl works 😂)

[mikeingold]

Yet another reason I'm a fan of Julia and functional programming: fewer worries about magical background state. 😆