Thanks to @notnoop for this UX improvement suggestion.
The allocation’s task group is always known, so it
might as well be preselected in the sidebar when the
exec window opens. Also, if the task group only has
one task, might as well preselect it too.
This closes#8422, another bug facilitated by the difficulty
of automated testing when opening another window. Thanks to
@notnoop for narrowing this down.
Bring Nomad in line with other HashiCorp projects and remove stalebot. We get
little value in cleaning up issues automatically this way, it adds extra work
for maintainers when we have issues waiting on the backlog that we intend to
do, and it presents an unkind experience to issue contributors who get their
issues closed by an impersonal bot.
The reconcile loop sets `DeploymentState.DesiredCanaries` only on the first
pass through the loop and if the job is not paused/pending. In MRD,
deployments will make one pass though the loop while "pending", and were not
ever getting `DesiredCanaries` set. We can't set it in the initial
`DeploymentState` constructor because the first pass through setting up
canaries expects it's not there yet. However, this value is static for a given
version of a job because it's coming from the update stanza, so it's safe to
re-assign the value on subsequent passes.
The field name `Deployment.TaskGroups` contains a map of `DeploymentState`,
which makes it a little harder to follow state updates when combined with
inconsistent naming conventions, particularly when we also have the state
store or actual `TaskGroup`s in scope. This changeset changes all uses to
`dstate` so as not to be confused with actual TaskGroups.
* nomad/structs/structs: add to Job.Validate
* Update nomad/structs/structs.go
Co-authored-by: Mahmood Ali <mahmood@hashicorp.com>
* nomad/structs/structs: match error strings to the config file
* nomad/structs/structs_test: clarify the test a bit
* nomad/structs/structs_test: typo in the test error comparison
Co-authored-by: Mahmood Ali <mahmood@hashicorp.com>
If a user is just clicking / copy-pasting, they could accidently think they next gcloud commands should be run inside the server VM.
Removing that extra bit of information to make accessing the UIs as simple as possible. Moreover, the local commands on the cloud shell should just work without needing to SSH into the server VM.
It was tricky to get the web preview expierince to work smoothly on non-standard HTTP ports. But, I was able to figure out the link the web preview button uses under-the-hood, and add custom query string params.
This will automatically pass along the environment variables set in a previous step, and prevent users from manually needed to type in the values in the CLI.
So the comand is easily copyable, and consistent with the rest. However, this is probably not totally necessary in the cloud shell itself since the gcloud command will likely been initialized already.
Since this tutorial also links to a GCP cloud shell tutorial, we want to make sure all the command blocks are easily copyable to make that expierince smooth.
