showyourwork
An invalid git hash is frequently saved in last_commit_sha.txt
On the workflow run for my dfm/araa-gps project the article cache restore seems to always fail because an invalid hash is being saved to last_commit_sha.txt. This causes the cache restore to fail, and means that the figure scripts never get run without re-setting the cache. I assume that the cause is that we're dirtying the repo somehow during the build and I'll try to track that down, but it would probably be good to handle this case. Some things that perhaps should happen:
- If the cache restore / mod time update fails, we should probably remove the cache and re-run the scripts.
- We probably want to write
last_commit_sha.txtbefore running the build.
Can 1. be done easily? We're overwriting stuff in the repo when we restore from cache. We might have to wipe the cwd and re-clone the repo in order to achieve that? I suggested simply failing the build and asking the user to bump the cache, but if we can do it your way it's certainly preferable.
Also, do you have a sense as to why last_commit_sha.txt is not getting updated at the end of the build (since the build itself is passing)?
https://github.com/showyourwork/showyourwork/blob/main/showyourwork/cli/commands/cache.py#L81-L91
In your latest build it seems to be updating the cache: https://github.com/dfm/araa-gps/actions/runs/3053508686/jobs/4924221075#step:3:146
Yes! I've figured it out. It's because of the Overleaf integration. The commit updating from Overleaf never ends up on GitHub because it doesn't push. So, if there are any Overleaf changes to integrate, last_commit_sha.txt always points to a non-existent commit!
In your latest build it seems to be updating the cache: https://github.com/dfm/araa-gps/actions/runs/3053508686/jobs/4924221075#step:3:146
No. The problem is in the restore step: https://github.com/dfm/araa-gps/actions/runs/3053508686/jobs/4924221075#step:3:131
It still (silently) fails.
The file last_commit_sha.txt gets updated here, at the end of the build. That step is definitely running according to your build logs. But as you said, it's probably constantly updating it with the Overleaf commit.
This should be a straightforward fix, at any rate. I can get to it this afternoon if you don't beat me to it.
Awesome - I'm not clear on the best way to handle it, so I trust you! Hopefully we can do something more sensible with the new overleaf interface.
As a short term fix, I've added a git push step to my workflow, which I think should fix things if this truly is the issue...