Commit sha by github-action always one behind the commit sha displayed in GitHub GUI

I noticed something peculiar today. The commit sha showed at the top right corner did not match the commit sha in my index.html file. Upon further investigation it turned out that the commit sha in my file always has a parent which is the commit sha shown in GUI

I run a github-action weekly and the action itself commits the files. I have a python script that uses 

os.environ['GITHUB_SHA']

environment variable available through github-actions for writing the commit sha in the file, which always trails what is shown in the GUI.

I suspect that since the commit happens AFTER I access the os.environ['GITHUB\_SHA'] thats why the sha in the file always lags behind. 

But this means I have been displaying incorrect information about the commit sha that is responsible for the latest file contents.

Q) Is there a means to actually write the correct sha (matching sha as the GitHub GUI) in the file while using github-actions?

Please have a look at the repository here to investigate I just said above.

I suspect that since the commit happens AFTER I access the os.environ['GITHUB\_SHA'] thats why the sha in the file always lags behind. 

Yeah, that is exactly what is going on. The SHA of a commit is generated during the commit and when at that point, the “GITHUB_SHA” still points to the commit that triggered the workflow (so the previous commit so to say).

This is inherent to how git works and how the SHA is created. Based on your use case, you need to know this SHA in advance as it is being part of the commit. As far as I know, it is impossible.

If possible in your use case, I think a solution could be to have the HTML page retrieve the latest commit SHA using the API (https://developer.github.com/v3/repos/commits/#list-commits-on-a-repository).

Also, you could have the files that you want to have the content at, e.g. “index.html” in this case, in a seperate branch. So the “index.html” in e.g. the “docs” branch could point to an actual commit of the “master” branch without any problem since the SHA of the commit in the “master” branch can be know at the time and you don’t have the (impossible) issue of an item in an commit needing to have the SHA of that commit.

@jdbruijn  Yeah, it looks like I would have to use javascript to make API calls and update it in the index.html page. Using API calls in the Python script that runs in the runner would lead to the same issue.

However, your second reply has intrigued me. I am afraid I may not have understood it completely.

Now, the process of writing the commit sha in the index.html file is an automated one as you might have seen from the repository. It happens through the python script run by the github runner.

Are you suggesting that I make the commit in master branch, then checkout to a different branch(say “gh-pages”), somehow access master’s commit sha from gh-pages and write it in the index.html in gh-pages branch which is then published as a github page/website?

But won’t accessing the sha using environment variable give me the sha in gh-pages branch itself? I am afraid I am not able to think how this would work?

Were you alluding to this or did I completely miss your point?

I think you got the gist of it.

I haven’t looked too much in what your script does, but if it generates all content that is going to be on the gh-pages branch, you can generate it from the master branch, without having the SHA issue.

Lets run through the steps globally.

  1. Your workflow is trigered every week and will checkout the latest version on master branch. Note that the SHA is that of the latest commit on the master branch, which is the one you want.
  2. You run your script, which generates all files you want and puts them in some directory (lets say this is a directory called “pages” for the moment). Again, note that the SHA is of the latest master commit, so you can still use that in your script to write the contents of index.html. 
  3. Now you’d want to push the contents of the “pages” directory to the “gh-pages” branch. You can either use an action to do this, a quick search on the Marketplace gives you some options (e.g. this one), or you can checkout the “gh-pages” branch manually, copy the contents of the pages directory back to the root and commit those.

Now, I haven’t tested any of this so don’t have a complete workflow or anything for you. Nonetheless, I think what I described above should give you enough information to write the workflow.