Iron out submodule caching support
Closed this issue · 4 comments
Related problem
PR #51 introduced submodule caching support, which greatly sped up workflow execution times. However, while doing sya-ri/PackSquash-action-test#1 I've stumbled upon an unhandled exception related to the changes introduced in that PR.
That particular problem was fixed, but this fact and the lack of thorough testing of that PR suggest that there might be some relevant issues left.
Proposed solution
Submodule caching support should be thoroughly tested and reviewed before the next action version is released. Maybe my fix was enough to iron things out, but I didn't test complex scenarios such as nested submodules.
Alternative solutions
- Do nothing. This is a risky proposition that I'd rather avoid.
- Revert the PR. This would be sad, because it contains useful changes, and I would not like to do that. However, it would guarantee that no new failures are introduced due to submodule caching.
Additional context
@sya-ri was the original author of the PR and stated that the action "may need some changes" in response, but his unavailability and lack of commitment to look into the matter over the past months warrant this task to be written down and another pair of eyes to look at the problem.
I think that it throws an exception if it contains uncommitted files. I think there are other causes, but we need more research.
Okay. That's useful to know.
[...] warrant [...] another pair of eyes to look at the problem.
Do you think it still is warranted? In other words, will I have to take care of this at some point, alone?
Edit: a lack of answer to the previous question will be interpreted as uncooperative unavailability.
This is not really related to the issue at hand, but while ironing out stuff I've fixed problem matchers being broken by default since the action uses PackSquash with colored output: 11fa3f7
Good riddance to probably most of the caching issues that were left! 🎉
Addressed by #55.