e206993d49
* TaggedVersion information in structs, rather than job_endpoint (#23841) * TaggedVersion information in structs, rather than job_endpoint * Test for taggedVersion description length * Some API plumbing * Tag and Untag job versions (#23863) * Tag and Untag at API level on down, but am I unblocking the wrong thing? * Code and comment cleanup * Unset methods generally now I stare long into the namespace abyss * Namespace passes through with QueryOptions removed from a write requesting struct * Comment and PR review cleanup * Version back to VersionStr * Generally consolidate unset logic into apply for version tagging * Addressed some PR comments * Auth check and RPC forwarding * uint64 instead of pointer for job version after api layer and renamed copy * job tag command split into apply and unset * latest-version convenience handling moved to CLI command level * CLI tests for tagging/untagging * UI parts removed * Add to job table when unsetting job tag on latest version * Vestigial no more * Compare versions by name and version number with the nomad history command (#23889) * First pass at passing a tagname and/or diff version to plan/versions requests * versions API now takes compare_to flags * Job history command output can have tag names and descriptions * compare_to to diff-tag and diff-version, plus adding flags to history command * 0th version now shows a diff if a specific diff target is requested * Addressing some PR comments * Simplify the diff-appending part of jobVersions and hide None-type diffs from CLI * Remove the diff-tag and diff-version parts of nomad job plan, with an eye toward making them a new top-level CLI command soon * Version diff tests * re-implement JobVersionByTagName * Test mods and simplification * Documentation for nomad job history additions * Prevent pruning and reaping of TaggedVersion jobs (#23983) tagged versions should not count against JobTrackedVersions i.e. new job versions being inserted should not evict tagged versions and GC should not delete a job if any of its versions are tagged Co-authored-by: Daniel Bennett <dbennett@hashicorp.com> --------- Co-authored-by: Daniel Bennett <dbennett@hashicorp.com> * [ui] Version Tags on the job versions page (#24013) * Timeline styles and their buttons modernized, and tags added * styled but not yet functional version blocks * Rough pass at edit/unedit UX * Styles consolidated * better UX around version tag crud, plus adapter and serializers * Mirage and acceptance tests * Modify percy to not show time-based things --------- Co-authored-by: Daniel Bennett <dbennett@hashicorp.com> * Job revert command and API endpoint can take a string version tag name (#24059) * Job revert command and API endpoint can take a string version tag name * RevertOpts as a signature-modified alternative to Revert() * job revert CLI test * Version pointers in endpoint tests * Dont copy over the tag when a job is reverted to a version with a tag * Convert tag name to version number at CLI level * Client method for version lookup by tag * No longer double-declaring client * [ui] Add tag filter to the job versions page (#24064) * Rough pass at the UI for version diff dropdown * Cleanup and diff fetching via adapter method * TaggedVersion now VersionTag (#24066) --------- Co-authored-by: Daniel Bennett <dbennett@hashicorp.com>
Nomad UI
The official Nomad UI.
Prerequisites
This is an ember.js project, and you will need the following tools installed on your computer.
Installation
The Nomad UI gets cloned along with the rest of Nomad. To install dependencies, do the following from the root of the Nomad project:
$ cd ui
$ yarn
Running / Development
UI in development mode defaults to using fake generated data, but you can configure it to proxy a live running nomad process by setting USE_MIRAGE environment variable to false. First, make sure nomad is running. The UI, in development mode, runs independently from Nomad, so this could be an official release or a dev branch. Likewise, Nomad can be running in server mode or dev mode. As long as the API is accessible, the UI will work as expected.
USE_MIRAGE=false ember serve- Visit your app at http://localhost:4200.
You may need to reference the direct path to ember, typically in ./node_modules/.bin/ember.
The fake data in development is generated from a stable seed of 1. To generate different data, you can include a query parameter of ?faker-seed=2 or any other number in the URL. To turn off the seed and get different data with every load, use ?faker=seed=0.
When running with Mirage, the default scenario is set in config/environment.js but can be overridden with a query parameter to any of the scenarios named in mirage/scenarios/default.js with something like ?mirage-scenario=emptyCluster.
Running / Development with Vagrant
All necessary tools for UI development are installed as part of the Vagrantfile. This is primarily to make it easy to build the UI from source while working on Nomad. Due to the filesystem requirements of Broccoli (which powers Ember CLI), it is strongly discouraged to use Vagrant for developing changes to the UI.
That said, development with Vagrant is still possible, but the ember serve command requires two modifications:
--watch polling: This allows the vm to notice file changes made in the host environment.--port 4201: The default port 4200 is not forwarded, since local development is recommended.
This makes the full command for running the UI in development mode in Vagrant:
$ ember serve --watch polling --port 4201
Running Tests
Nomad UI tests can be run independently of Nomad golang tests.
ember test(single run, headless browser)ember test --server(watches for changes, runs in a full browser)
You can use --filter <test name> to run a targetted set of tests, e.g. ember test --filter 'allocation detail'.
In the test environment, the fake data is generated with a random seed. If you want stable data, you can set a seed while running the test server by appending &faker-seed=1 (or any other non-zero number) to the URL.
Linting
yarn lintyarn lint:fix
Building
Typically make release or make dev-ui will be the desired build workflow, but in the event that build artifacts need to be inspected, ember build will output compiled files in ui/dist.
ember build(development)ember build --environment production(production)
Releasing
Nomad UI releases are in lockstep with Nomad releases and are integrated into the make release toolchain.
Conventions
- UI branches should be prefix with
f-ui-for feature work andb-ui-for bug fixes. This instructs CI to skip running nomad backend tests.
Troubleshooting
The UI is running, but none of the API requests are working
By default (according to the .ember-cli file), a proxy address of http://localhost:4646 is used. If you are running Nomad at a different address, you will need to override this setting when running ember serve: ember serve --proxy http://newlocation:1111.
Also, ensure that USE_MIRAGE environment variable is set to false, so the UI proxy requests to Nomad process instead of using autogenerated test data.
Nomad is running in Vagrant, but I can't access the API from my host machine
Nomad binds to 127.0.0.1:4646 by default, which is the loopback address. Try running nomad bound to 0.0.0.0: bin/nomad -bind 0.0.0.0.
Ports also need to be forwarded in the Vagrantfile. 4646 is already forwarded, but if a port other than the default is being used, that port needs to be added to the Vagrantfile and vagrant reload needs to be run.