app ls --status
shows more detailles about the deployment state
#280
No reviewers
Labels
No Label
bug
build
ci/cd
contributing
design
documentation
duplicate
enhancement
help wanted
invalid
meta
question
release
release-candidate
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#280
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "detailed_app_list"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR adds the chaos state, the chaos version and the autoupdate state to the deployment details of
abra app ls --status
.The label
coop-cloud.<app_name>.chaos_version
is used to store the chaos version. This solves coop-cloud/organising#429Amazing work @moritz! Love this change and it will really help us. The table output is getting quite long now, so I'm wondering if folks have concerns about that? I think each column is pretty useful to have. Especially when we have a chaos deployment label but no version, that can happen with todays
abra
. But then again, that won't be the case later, in say, a years time? If you have a chaos labeled deploy then you will have the version? We could merge these columns potentially, I'm not sure. Or maybe remove it later on?@ -183,6 +183,7 @@ recipes.
config.ExposeAllEnv(stackName, compose, app.Env)
config.SetRecipeLabel(compose, stackName, app.Recipe)
config.SetChaosLabel(compose, stackName, internal.Chaos)
config.SetChaosVersionLabel(compose, app.StackName(), chosenDowngrade)
app.StackName()
->stackName
@ -194,6 +194,7 @@ recipes.
config.ExposeAllEnv(stackName, compose, app.Env)
config.SetRecipeLabel(compose, stackName, app.Recipe)
config.SetChaosLabel(compose, stackName, internal.Chaos)
config.SetChaosVersionLabel(compose, app.StackName(), chosenUpgrade)
app.StackName()
->stackName
@ -139,6 +139,7 @@ func DeployAction(c *cli.Context) error {
config.ExposeAllEnv(app.StackName(), compose, app.Env)
config.SetRecipeLabel(compose, app.StackName(), app.Recipe)
config.SetChaosLabel(compose, app.StackName(), Chaos)
config.SetChaosVersionLabel(compose, app.StackName(), version)
Oops, can we make all the
app.StackName()
calls onestackName
too? To avoid computing this several times...@ -407,0 +409,4 @@
result["chaos"] = chaos
}
labelKey = fmt.Sprintf("coop-cloud.%s.chaos_version", name)
chaos_version
->chaos-version
following the convention of-
? This would require updating in several places in this PR.@ -407,0 +414,4 @@
result["chaosVersion"] = chaosVersion
}
labelKey = fmt.Sprintf("coop-cloud.%s.autoupdate", name)
Is
autoupdate
->auto-update
potentially more readable?This would be a bit more readable but it would break kadabra for for all apps that are deployed with the current abra version.
Kadabra is still alpha, so breaking changes are part of it, but I don't think this label change is really worth the effort to redeploy all apps after the next abra release.
4bb2fb6b63
toedff63b446