skip deploy if no changes except sitemap

[aogier]

Hi, I'm looking at this tool for introducing a versioning workflow on my docs site and I noted a behaviour that I can understand but I wonder if I could change it.
Basically, with a current doc site, with those three commands:

• mike deploy --update-aliases 0.1 dev
• mike deploy --update-aliases 0.2 dev
• mike deploy --update-aliases 0.2 dev

I obtain three commits on my pages branch, with only the first two being useful:

$ git log -n3 --stat

commit 74c68d53619620aa53074c392016bda4a1de49c0
Author: Alessandro Ogier <alessandro.ogier@gmail.com>
Date:   Fri Jun 3 08:19:20 2022 +0100

    Deployed 8ffa88a to 0.2 with MkDocs 1.3.0 and mike 1.1.2

 0.2/sitemap.xml.gz | Bin 195 -> 195 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

commit 0eabdf68baeb084c4f03693ebb33f7abb0060dd7
Author: Alessandro Ogier <alessandro.ogier@gmail.com>
Date:   Fri Jun 3 08:18:19 2022 +0100

    Deployed 8ffa88a to 0.2 with MkDocs 1.3.0 and mike 1.1.2

 0.2/404.html                                       |    1 +
 0.2/assets/images/favicon.png                      |  Bin 0 -> 1870 bytes
[...]
 versions.json                                      |    2 +-
 45 files changed, 7370 insertions(+), 10 deletions(-)

commit d6718a12fcd2f151e1dd7c83b716dfb588d9f5fe
Author: Alessandro Ogier <alessandro.ogier@gmail.com>
Date:   Fri Jun 3 08:17:41 2022 +0100

    Deployed 8ffa88a to 0.1 with MkDocs 1.3.0 and mike 1.1.2

 0.1/manage/groups/index.html |   2 +-
 0.1/sitemap.xml.gz           | Bin 195 -> 195 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)

while it's clear why this is happening and I don't think is gonna change mkdocs-side, I wonder if I could somehow hook commit process mike-side and skip commits where the only change is sitemap file (ie. no actual changes).

This would allow for a workflow where I run mike deploy --update-aliases $(cat docs_version) dev during every project's CI run, without having useless updates to pages branch which in turn would trigger other useless actions eg. build a container w/ docs and republish on my internal systems etc

What do you think? I'd be glad to contribute such a feature if there is interest on that

regards, ciao!

[jimporter]

I think the way to do this would be to only run mike deploy if "interesting" files in the source branch (e.g. mkdocs.yml or stuff under docs/) have changed. I suppose you could also write a shell script to drop commits after the fact instead, based on the diff.

I don't think mike should have any logic to avoid useless commits, since that adds extra complexity when the only benefit is that the commit log is shorter (and the repo size is slightly smaller over time). As far as I can see, it doesn't actually break anything.

My goal with mike is to keep is as simple as possible so that maintenance is less of a burden (in fact, it already does significantly more than I personally care about, and thus has a higher maintenance burden than I'd like).

[leonardehrenfried]

@aogier Have you found a solution for this? While I acknowledge that it's not mike's responsibility to do something about it, there appears to be no way to disable generation of the sitemap or exclusion of it from the git repo.

I even added it to .gitignore but mike still adds it.

Any ideas? I do not care about the sitemap and would be fine with it being totally disabled.

[aogier]

stopped using this, but iirc capping CI runs to the last one only, ie. other running runs are killed, did the trick @leonardehrenfried

[jimporter]

Looking at this again, I think you could do something like the following before building your docs:

export SOURCE_DATE_EPOCH=git log -1 --format=%ct <directories containing your documentation sources>

This would set the build date of your docs to be the date of the latest commit to any of your doc sources. Thus, if you haven't changed your sources, the date shouldn't change, and then neither will sitemap.xml.gz.

[aogier]

thank you, I got rid of mike long time ago but I'm sure somebody else could appreciate that

[leonardehrenfried]

I for sure will try it out.

[jimporter]

Relevant to this, I added the ability for mike to avoid producing empty commits (i.e. no diff) in 99d0189715266daee65719d32af157d2916ec957. (Technically, this drops the commit it generated if it realizes that it was empty.) Combined with the SOURCE_DATE_EPOCH trick, I think this should mean that you can unconditionally call mike deploy, and it will only commit if there are changes.

I actually thought fast-import did this for free, but apparently not.