containers / containers/fetchit
Rollback to known good commits (or not)
- Dominant language
- Go
- Stars
- 169
- Forks
- 23
- PR merge metrics
- No merged PRs in 30d
Description
* Should fetchIt rollback to a last know good commit when it encounters an `Apply` error?
* Should fetchIt track back commits and refuse to checkout a bad commit?
In previous discussions we thought yes to both and there is a [PR ](https://github.com/containers/fetchit/pull/209) in the works for this ^^ however I think we should not track bad commits at this time, because it is impossible for FetchIt to know what a bad commit is.
I think rollback is useful, but tracking bad commits might be out of scope. Here's why:
If rollback & TrackBadCommits is enabled - but the fix is outside the git code - like, a directory is supposed to exist on the host that doesn't - that would result in a workflow that can never progress to a good state because it's not the commit that's broken, it's the host. So, I think this means we can never confidently enable TrackBadCommits - there is no way for fetchit to know if the issue is the code in the commit or something else on the host.
btw, I'll point out that it was my (bad?) idea to track bad commits in the first place :)
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.