containers / containers/fetchit

Rollback to known good commits (or not)

Open
#242 0 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.