Verify if the submitted manifest YAML is consistent with the git repository
iszulcdeepsense opened this issue · comments
Racetrack could check if the submitted manifest.yaml is consistent with the one found in the git repository of the Job's source code.
Discrepancies may happen, if someone forgets to push the local changes to git repository. A sort of warning would prevent from such inconsistencies.
Notes:
- this may be an optional setting that will be enabled on test/preprod/prod environments
- this may also check for not-pushed / dirty state of repository (in general, output of
git statusshould beYour branch is up to dateandnothing to commit, working tree clean)
Just to be annoying and distracting, if we have to submit a manifest, and also a manifest (identical or not) is present in the git repo, don't we have a design problem?
Just to be annoying and distracting, if we have to submit a manifest, and also a manifest (identical or not) is present in the git repo, don't we have a design problem?
@JosefAssadERST That's a good, interesting point. In a sense, the manifest is self-referential by pointing to a place where its official version can be found. Likewise, git repositories can exist in multiple copies in different places, while they all usually point to the central remote, which is a source of truth.
I wouldn't say it's a design problem. We allow multiple copies, but we strive to keep them in sync.
Just to be annoying and distracting, if we have to submit a manifest, and also a manifest (identical or not) is present in the git repo, don't we have a design problem?
the manifest is self-referential by pointing to a place where its official version can be found.
I'm not sure if self-referential is a euphemism and it's actually awkward. When I say I'm not sure I mean I'm not sure, I don't mean I'm sure.
Likewise, git repositories can exist in multiple copies in different places, while they all usually point to the central remote, which is a source of truth. I wouldn't say it's a design problem. We allow multiple copies, but we strive to keep them in sync.
Well in a way I suppose. But in this analogy, you're supposed to and will (usually?) build from the source of truth, not from a clone that may be behind or ahead.
It's analogy Friday, so here's one for you. What if, when you make a docker image, you have to supply the daemon with a Dockerfile, but also a git remote where it should expect a Dockerfile in the root? Seems awkward to me.
I have successfully derailed this issue entirely, but since it's such a fundamental observation which isn't entirely sure yet, I am hesitant to split it off in its own issue.