With the Ember update, when the will-destroy action is called
to check the element height, its height is already zero. That
seems strange but I didn’t look into it any further, as
using did-insert to store the element lets us check its height
before any other actions when a processing button is pressed.

UI: Line chart decomposed

docs: add two community PRs to changelog

fix: parse_service: return err instead of panic

Service and Check on_update configuration option (readiness checks)

docs: update link to the Nomad Autoscaler demos

consul/connect: correctly detect when connect tasks not updated

This PR fixes a bug where tasks with Connect services could be
triggered to destructively update (i.e. placed in a new alloc)
when no update should be necessary.

Fixes #10077

Refactor StatsTimeSeries component to be a glimmer component and use composition instead of inheritance

Wraps up a common pattern used in charts for building a a string that
incorporates the ember guid

CHANGELOG entries for some 1.0.4 UI bug fixes

Fixes https://github.com/hashicorp/nomad/issues/10072

The old URL redirects to https://learn.hashicorp.com/nomad

Add devices to AllocatedTaskResources

dist: place systemd unit options correctly

This PR places StartLimitIntervalSec and StartLimitBurst in the
Unit section of systemd unit files, rather than the Service section.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Fixes #10065

In a deployment with two groups (ex. A and B), if group A's canary becomes
healthy before group B's, the deadline for the overall deployment will be set
to that of group A. When the deployment is promoted, if group A is done it
will not contribute to the next deadline cutoff. Group B's old deadline will
be used instead, which will be in the past and immediately trigger a
deployment progress failure. Reset the progress deadline when the job is
promotion to avoid this bug, and to better conform with implicit user
expectations around how the progress deadline should interact with promotions.

consul/connect: Fix bug where connect sidecar services would be unnecessarily re-registered

This PR fixes a bug where sidecar services would be re-registered into Consul every ~30
seconds, caused by the parent service having its tags field set and the sidecar_service
tags unset. Nomad would directly compare the tags between its copy of the sidecar service
definition and the tags of the sidecar service reported by Consul. This does not work,
because Consul will under-the-hood set the sidecar service tags to inherit the parent
service tags if the sidecar service tags are unset. The comparison then done by Nomad
would not match, if the parent sidecar tags are set.

Fixes #10025