Better dependency tracking between updater <- backend

[tylerauerbeck]

Currently we've got two modules in this repository: backend and updater. As neither of these are versioned, this requires us to go grab the latest from backend each time we make an update so that updater is working from the latest changes that we've made.

What this results in is two changes for each one that we make since we first need to merge the changes into backend so they can then be picked up by updater.

Is this the best setup to accomplish what we're wanting to do? Are two separate modules providing the value that is intended?

[ervcz]

The updater is a standalone Omaha client library with zero production dependencies on the backend. The friction comes from the updater's tests using the backend to spin up a real Omaha server for integration testing.

Both the updater and the frontend modules are clients for the backend and were developed together. The setup is not perfect but it's simple.

1. The updater's backend dependency is pinned to a 2021 version via COMMIT hash
2. Dependabot can't auto-update pseudo-versions (v0.0.0-...) due to pinning it to a commit.

My recommendation to eliminate the friction is:

1. For local development, add to updater/go.mod: replace github.com/kinvolk/nebraska/backend => ../backend (don't commit it) This lets you test against local backend changes immediately.
2. Update the outdated dependency: cd updater && go get -u github.com/kinvolk/nebraska/backend@latest && go mod tidy Use tagged backend releases (e.g., backend/v0.1.0) so Dependabot can handle updates automatically (we already have a dependabot entry for the updater).