Automate dependency upgrades

[DazWilkin]

Is your feature request related to a problem? Please describe.

Akri comprises 4 members and each member comprises a list of crate dependencies. It is moderately important that Akri be kept current with its dependencies but it already drifts quite considerably (e.g. kube uses 0.23.0 published 30-Dec-2019 current is 0.46.0 published 02-Jan-2021).

Outdated dependencies potentially:

• include security vulnerabilities
• are feature poorer
• accrue technical debt.

Additionally, it is important to prune no-longer-needed dependencies in order to reduce:

• code-size
• attack surface
• complexity in managing dependencies.

Members:

members = [
    "shared",
    "controller",
    "agent",
    "samples/brokers/udev-video-broker"
]

Agent's Cargo.toml:

[dependencies]
async-stream = "0.2"
async-trait = "0.1.0"
blake2 = "0.8.0"
chrono = "0.4.10"
cfg-if = "0.1"
env_logger = "0.6.1"
failure = "0.1.5"
futures = { version = "0.3.1", package = "futures" }
futures-core = "0.3"
futures-util = "0.3"
futures-old = { version = "0.1", package = "futures" }
hyper = "0.11"
kube = { version = "0.23.0", features = ["openapi"] }
k8s-openapi = { version = "0.6.0", features = ["v1_16"] }
log = "0.4"
mime = "0.3"
mockall = "0.6.0"
pest = "2.0"
pest_derive = "2.0"
prost = "0.6"
rand = "0.7"
regex = "1"
serde = "1.0.104"
serde_json = "1.0.45"
serde_yaml = "0.8.11"
serde_derive = "1.0.104"
akri-shared = { path = "../shared" }
sxd-document = "0.3.0"
sxd-xpath = "0.4.0"
tempfile = "3.1.0"
tokio = { version = "0.2", features = ["full"] }
tokio-core = "0.1"
tokio-test = "0.3.0"
tonic = "0.1"
tower = "0.3" 
udev = "0.4"
uuid = { version = "0.8.1", features = ["v4"] }
xml-rs = "0.8.0"
yaserde = "0.3.13"
yaserde_derive = "0.3.13"
zeroconf = "0.6.2"

[build-dependencies]
tonic-build = "0.1.1"

Is your feature request related to a way you would like Akri extended? Please describe.

N/A

Describe the solution you'd like

The Akri project may wish to consider a(n automated) build process in which dependencies are:

• pruned as appropriate; only include those that are explicit, current dependencies
• upgraded to the latest (major+minor) versions to see "Will it build?" and remedial actions indicated when it doesn't

Describe alternatives you've considered

N/A

Additional context

E.g. see #180 (comment)

[romoh]

Folks, I've spent some time looking at this and here's my thought process.
Starting with "why we need to upgrade dependencies". It seems the P0 problem is security vulnerabilities. For that, I propose adding a new GitHub action to catch packages imposing security risks through #212

Next, for patch, minor and major updates. this is taken care by using cargo update which uses semVer common compatibility versioning to lock versions to existing dependencies. For that I'll add another GitHub actions that automatically run with each build, It will run cargo update and fails if an update was found. (later we can expand this to attempt a build and if build was successful, it can automatically open a pull request if changes were detected. If build failed, it fails the action notifying that a dependency was added without properly specifying the versioning semantics).

Finally non-compatible updates will still require manual intervention and can be taken care of each release manually if needed.

Let me know your thoughts..

[DazWilkin]

Thanks for taking the time to consider this!

Yes, to your P0 ... additionally, we may wish to consider leveraging a vuln checker on the container images that are produced as these often identify CVEs and could possibly create GitHub issues automatically.

It may be a P1 rather than P0 but (avoiding) incurring technical debt is "up there" with the drift too.

I assumed (probably incorrectly) that cargo update did not update on possibly breaking changes (e.g. v0 --> `v1) (link)

Are you familiar with dependabot? It may help.

[romoh]

Dependabot is enabled for Akri (the current GitHub integrated version), but doesn't detect the current security vulnerabilities. I'm guessing because it relies on GitHub Advisory Database and not the RustSec Advisory Database?

A vuln checker on container images is a good idea. I'll open a separate issue to track that.