Most tests bypass setting the token via the UI, instead choosing
to set it in localStorage directly, because the acceptance tests
for the token UI are sufficient to exercise that part of the UI,
so this speeds up the test a bit.
Closes#7197#7199
Note: Test coverage is limited to adapter and serializer unit tests. All
acceptance tests have been stubbed and all features have been manually
tested end-to-end.
This represents Phase 1 of #6993 which is the core workflow of CSI in
the UI. It includes a couple new pages for viewing all external volumes
as well as the allocations associated with each. It also updates
existing volume related views on job and allocation pages to handle both
Host Volumes and CSI Volumes.
This connects Xterm.js to a Nomad exec websocket so people
can interact on clients via live sessions. There are buttons on
job, allocation, task group, and task detail pages that open a
popup that lets them edit their shell command and start a
session.
More is to come, as recorded in issues.
This builds on API changes in #6017 and #6021 to conditionally turn off the
“Run Job” button based on the current token’s capabilities, or the capabilities
of the anonymous policy if no token is present.
If you try to visit the job-run route directly, it redirects to the job list.
I unintentionally introduced a flapping test in #6817. The
draining status of the node will be randomly chosen and
that flag takes precedence over eligibility. This forces
the draining flag to be false rather than random so the
test should no longer flap.
See here for an example failure:
https://circleci.com/gh/hashicorp/nomad/26368
There are two changes here, and some caveats/commentary:
1. The “State“ table column was actually sorting only by status. The state was not an actual property, just something calculated in each client row, as a product of status, isEligible, and isDraining. This PR adds isDraining as a component of compositeState so it can be used for sorting.
2. The Sortable mixin declares dependent keys that cause the sort to be live-updating, but only if the members of the array change, such as if a new client is added, but not if any of the sortable properties change. This PR adds a SortableFactory function that generates a mixin whose listSorted computed property includes dependent keys for the sortable properties, so the table will live-update if any of the sortable properties change, not just the array members. There’s a warning if you use SortableFactory without dependent keys and via the original Sortable interface, so we can eventually migrate away from it.
The recurring problem here was that sometimes the factories would
generate more than one task, and it was random whether the task
with the proxy task would be the first in the list. This ensures
that the proxy task is always first so the tests can run again.
This fixes a race condition in the pseudo-relationship between a
TaskState and a Task that was causing the Consul Connect proxy tag
to sometimes show on the wrong task. There’s no direct Ember Data-style
relationship between a TaskState and its Task; instead, it’s determined
by searching for a Task with the matching name. The related Task was
sometimes stored before everything was ready and not recalculated when
the name became known. This ensures the relationship is accurate if the
TaskState’s name property changes.
I put this property in the wrong place.
I’ve found how to fix the mock API in the tests but
they’re failing to pass with headless Chrome only,
so they’re skipped for now.
When sorting by size, directories are sorted by name, as size
isn’t displayed.
This includes a change to the positioning of sort arrows for all tables,
moving them closer to the text, because in some cases, the arrows
for right-aligned columns were ambiguously positioned.
This uses ember-page-title to add dynamic page titles throughout the
route hierarchy. When there’s more than one region, the current
current region is added before the final entry of “- Nomad”.
The draining, eligibility, and status fields now all show under a combined
state column. Draining takes precedence, then (in)eligibility; if neither of
those is true, the status displays.
