Mike deploy not updating to latest version

[kiroalbatrosa]

Hello,

I am using pages in github enterprise, when adding a new version to my documentation via acions(it is triggered by pushing/commiting to the docs folder in the main branch.

The automation calls a script on the listener that pulls the current repo and updates the pages site with mike deploy, for example: mike deploy --push --update-aliases 0.15 latest

What I observe is that :

1. The latest tag is not reflected in the versions.json file in the gh-pages branch, the tag stays with the previous version.
2. When executing the push command either manualy or via the pipeline, the update is reflected on the previous version(the one that has the latest tag)

How do I resolve this and make the deploy command act as it should- update specified version as given?

[jimporter]

This is difficult to debug without seeing the configs and your commit logs, but here are some things you can try:

• Make sure you're not using a shallow clone of the gh-pages branch
• Look at the diffs of the commits generated by mike to see what it's doing
• Try running mike deploy locally without pushing and then use mike serve to view the current state of your gh-pages branch

[kiroalbatrosa]

Hi jimporter,

Thank you for the suggestions, I see that maybe my process might be flawed from what you are saying. First though, mike deploy locally works fine, as well as when adding a new version to the documentation, problem is when I want to apply changes to a specific version, that is when the mentioned above is observed. So the process I have set up is that I clone the main branch and whenever I do a change in the docs folder for the documentation, and then apply either a new version with mike deploy --push --update-aliases latest or use the version number i wish to change/update. I do not clone any other branch than the main/master. Maybe the issue comes from my approach? As for what is happening is that when updating and not creating a new version, the deploy and changes happen in an older version that is not specified in the command(this happens when executing manually or via script) and the version where this happens holds the tag "latest" in versions.json in the gh-pages branch, the tag stays there no matter what or how I commit. The aliases for the versions.jason file are empty as well, and the tag "latest" is only for the version where changes get applied to.

[jimporter]

If you're using the default Github action to clone your repo, you'll probably need to do the following at minimum:

git fetch origin gh-pages --depth=1

By default, Github only clones the latest commit on your default branch, and mike depends on being able to see previous commits on your gh-pages branch. If simply adding that command doesn't work, you could probably add some instrumentation to your CI to check the state of your gh-pages branch before and after mike runes.

[kiroalbatrosa]

Hi @jimporter ,

So we have tried all the recomended steps and observe the same behavior described above. Mike deploy does not update the specified version, but instead the another version which has the tag "latest" which is reflected in versions.json, but when you create a new version with mike deploy the new version is created, the logs say that the commit is happening to the "old" version no matter if it is done manually or via script, with all the recomended steps.

This is the commit when using mike deploy --push --update-aliases 0.15 latest ci-bot Deployed 6de43fe to 0.13 with MkDocs 1.2.3 and mike 1.1.2

This is the content of versions.json in the gh-pages branch [{"version": "0.15", "title": "0.15", "aliases": []}, {"version": "0.13", "title": "0.13", "aliases": ["latest"]}, {"version": "0.12", "title": "0.12", "aliases": []}, {"version": "0.11", "title": "0.11", "aliases": []}, {"version": "0.10", "title": "0.10", "aliases": []}]

[jimporter]

Have you looked at the diff of the commit generated by mike before pushing? That might give you more information. I'd be extremely surprised if the command you showed actually generated that commit.

You could also try deploying to a different branch (--branch foobar) or testing on a different repository entirely. There could be an issue with something in Git.

If those don't work, the only thing left you could do is to run mike in a debugger and step through the entire process. In particular, looking at what gets sent to git fast-import would help verify that the commit is being generated properly.

[kiroalbatrosa]

Hi @jimporter , Is there a debug or verbose option for mike?

[jimporter]

Yes, the latest dev version has a mike --debug flag (it goes before the subcommand name). I'm not sure it'll tell you a whole lot that my other suggestions wouldn't, but you can try it.

[kiroalbatrosa]

Hi @jimporter ,

The issue was most likely caused by not staying in sync with the remote repo (https://github.com/jimporter/mike#staying-in-sync).

Using the GitHub actions/checkout@v2 should prevent such issues as the action executes /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/:refs/remotes/origin/ +refs/tags/:refs/tags/ to match the remote state.

Hope it helps for future versions :)

[jimporter]

Closing based on the above comment.