[merged] deploy: make sure commits are on the current branch

[jlebon]

A funky behaviour of rpm-ostree deploy was that specifying a csum
directly allowed you to jump to any commit, regardless of whether that
commit exists on the current branch or not. We tighten that up here so
that we check that the checksum does exist on the current branch.

The previous behaviour can be useful of course, but we might want to
change how users access it so that we don't get inconsistencies such as
rpm-ostree status saying that we're sitting on a specific branch with a
specific commit which doesn't actually belong to that branch.

---

This is split out from #465.

[cgwalters]

It feels a bit unfortunate to me to walk the whole ancestry if e.g. the user typos a commit ID. I guess I just feel that while this is conceptually an issue, we have a lot more important issues 😄

If we were looking at this problem, I'd say we should do this first: "One thing that would certainly help here is to show the fact that "deploy" was used in the status."

But...I guess on balance I'm OK merging this as is too. Leaving open for a reply, but I can do an r+ after a bit more discussion.

[jlebon]

It feels a bit unfortunate to me to walk the whole ancestry if e.g. the user typos a commit ID.

That's also an issue with version lookups though, right?

I guess I just feel that while this is conceptually an issue, we have a lot more important issues 😄

Heh, definitely don't disagree here :). This is more of a UI polishing item than a necessity. It just struck me as odd to have this asymmetry between versions and checksums.

If we were looking at this problem, I'd say we should do this first: "One thing that would certainly help here is to show the fact that "deploy" was used in the status."

Hmm, I think that's only worth it if we implement the second part of what you said re. making deploy sticky. But either way, ISTM that the ref resetting issue mentioned in the other PR feels wrong.

It's not that rollback doesn't change back the ref, but that the ref has any coupling with active deployments at all. At any point in time, I would expect e.g. ostree admin deploy my/remote/ref to deploy whatever is the latest thing we have downloaded so far, regardless of what ostree admin upgrade --override-commit=$csum I might have done previously.

[cgwalters]

@rh-atomic-bot r+ 05fbdc6

[rh-atomic-bot]

⌛ Testing commit 05fbdc6 with merge 2d07772...

[cgwalters]

Re changing the ref...yeah it's messy. We could try to redesign it at some point.

[rh-atomic-bot]

☀️ Test successful - status-atomicjenkins
Approved by: cgwalters
Pushing 2d07772 to master...