In this case we should probably skip running in place modification. It doesn't make sense to run in place modifications using configuration which is already out of date. Rather we should skip it and run on the latest configuration.
Right now the code always runs on the latest configuration even when triggered via a different commit; e.g. suppose we have commits
abcdef (older)
123456 (newer)
Then its possible the run triggered by abcdef will execute when 123456 is the latest commit. The renderer will use the commit from 123456. However, its confusing that the checkrun on abcdef is using code from a different commit. It makes more sense for the checkrun on abcdef to be skipped because it is no longer the latest commit.
30 Added a GitHubApp that runs in place modification on every push and creates a PR to check in the changes.
Its possible that the renderer ends up getting triggered on a commit that is behind head. https://github.com/jlewi/hydros/pull/30/files#diff-ad303975c31a2f01c500848b146471057f1a22957f224914d4e43061f9f115dfR103
In this case we should probably skip running in place modification. It doesn't make sense to run in place modifications using configuration which is already out of date. Rather we should skip it and run on the latest configuration. Right now the code always runs on the latest configuration even when triggered via a different commit; e.g. suppose we have commits abcdef (older) 123456 (newer)
Then its possible the run triggered by abcdef will execute when 123456 is the latest commit. The renderer will use the commit from 123456. However, its confusing that the checkrun on abcdef is using code from a different commit. It makes more sense for the checkrun on abcdef to be skipped because it is no longer the latest commit.