2017-06-26 23:46:34 +02:00
|
|
|
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
|
2017-02-26 22:06:33 +01:00
|
|
|
|
2017-04-12 19:38:12 +02:00
|
|
|
package main
|
2017-02-26 22:06:33 +01:00
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"io/ioutil"
|
|
|
|
"os"
|
|
|
|
"path/filepath"
|
|
|
|
"strconv"
|
|
|
|
|
2017-04-19 23:46:50 +02:00
|
|
|
"github.com/pkg/errors"
|
2017-02-26 22:06:33 +01:00
|
|
|
"github.com/spf13/cobra"
|
|
|
|
|
2017-08-02 18:25:22 +02:00
|
|
|
"github.com/pulumi/pulumi-fabric/pkg/encoding"
|
|
|
|
"github.com/pulumi/pulumi-fabric/pkg/tokens"
|
|
|
|
"github.com/pulumi/pulumi-fabric/pkg/util/cmdutil"
|
|
|
|
"github.com/pulumi/pulumi-fabric/pkg/workspace"
|
2017-02-26 22:06:33 +01:00
|
|
|
)
|
|
|
|
|
2017-03-06 15:32:39 +01:00
|
|
|
func newEnvLsCmd() *cobra.Command {
|
2017-02-26 22:06:33 +01:00
|
|
|
return &cobra.Command{
|
|
|
|
Use: "ls",
|
|
|
|
Aliases: []string{"list"},
|
2017-03-06 15:32:39 +01:00
|
|
|
Short: "List all known environments",
|
2017-04-12 20:12:25 +02:00
|
|
|
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
|
2017-03-07 14:47:42 +01:00
|
|
|
// Read the environment directory.
|
2017-03-06 15:32:39 +01:00
|
|
|
path := workspace.EnvPath("")
|
2017-02-26 22:06:33 +01:00
|
|
|
files, err := ioutil.ReadDir(path)
|
|
|
|
if err != nil && !os.IsNotExist(err) {
|
2017-04-19 23:46:50 +02:00
|
|
|
return errors.Errorf("could not read environments: %v", err)
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
fmt.Printf("%-20s %-48s %-12s\n", "NAME", "LAST DEPLOYMENT", "RESOURCE COUNT")
|
Make major commands more pleasant
This change eliminates the need to constantly type in the environment
name when performing major commands like configuration, planning, and
deployment. It's probably due to my age, however, I keep fat-fingering
simple commands in front of investors and I am embarrassed!
In the new model, there is a notion of a "current environment", and
I have modeled it kinda sorta just like Git's notion of "current branch."
By default, the current environment is set when you `init` something.
Otherwise, there is the `coco env select <env>` command to change it.
(Running this command w/out a new <env> will show you the current one.)
The major commands `config`, `plan`, `deploy`, and `destroy` will prefer
to use the current environment, unless it is overridden by using the
--env flag. All of the `coco env <cmd> <env>` commands still require the
explicit passing of an environment which seems reasonable since they are,
after all, about manipulating environments.
As part of this, I've overhauled the aging workspace settings cruft,
which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
|
|
|
curr := getCurrentEnv()
|
2017-02-26 22:06:33 +01:00
|
|
|
for _, file := range files {
|
|
|
|
// Ignore directories.
|
|
|
|
if file.IsDir() {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
|
|
|
// Skip files without valid extensions (e.g., *.bak files).
|
2017-03-06 15:32:39 +01:00
|
|
|
envfn := file.Name()
|
|
|
|
ext := filepath.Ext(envfn)
|
2017-02-26 22:06:33 +01:00
|
|
|
if _, has := encoding.Marshalers[ext]; !has {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2017-03-07 14:47:42 +01:00
|
|
|
// Read in this environment's information.
|
2017-03-06 15:32:39 +01:00
|
|
|
name := tokens.QName(envfn[:len(envfn)-len(ext)])
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
target, snapshot, checkpoint := readEnv(name)
|
|
|
|
if checkpoint == nil {
|
2017-03-06 15:32:39 +01:00
|
|
|
continue // failure reading the environment information.
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Now print out the name, last deployment time (if any), and resources (if any).
|
|
|
|
lastDeploy := "n/a"
|
|
|
|
resourceCount := "n/a"
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
if checkpoint.Latest != nil {
|
|
|
|
lastDeploy = checkpoint.Latest.Time.String()
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
if snapshot != nil {
|
|
|
|
resourceCount = strconv.Itoa(len(snapshot.Resources))
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
Make more progress on the new deployment model
This change restructures a lot more pertaining to deployments, snapshots,
environments, and the like.
The most notable change is that the notion of a deploy.Source is introduced,
which splits the responsibility between the deploy.Plan -- which simply
understands how to compute and carry out deployment plans -- and the idea
of something that can produce new objects on-demand during deployment.
The primary such implementation is evalSource, which encapsulates an
interpreter and takes a package, args, and config map, and proceeds to run
the interpreter in a distinct goroutine. It synchronizes as needed to
poke and prod the interpreter along its path to create new resource objects.
There are two other sources, however. First, a nullSource, which simply
refuses to create new objects. This can be handy when writing isolated
tests but is also used to simulate the "empty" environment as necessary to
do a complete teardown of the target environment. Second, a fixedSource,
which takes a pre-computed array of objects, and hands those, in order, to
the planning engine; this is mostly useful as a testing technique.
Boatloads of code is now changed and updated in the various CLI commands.
This further chugs along towards pulumi/lumi#90. The end is in sight.
2017-06-10 20:50:47 +02:00
|
|
|
display := target.Name
|
Make major commands more pleasant
This change eliminates the need to constantly type in the environment
name when performing major commands like configuration, planning, and
deployment. It's probably due to my age, however, I keep fat-fingering
simple commands in front of investors and I am embarrassed!
In the new model, there is a notion of a "current environment", and
I have modeled it kinda sorta just like Git's notion of "current branch."
By default, the current environment is set when you `init` something.
Otherwise, there is the `coco env select <env>` command to change it.
(Running this command w/out a new <env> will show you the current one.)
The major commands `config`, `plan`, `deploy`, and `destroy` will prefer
to use the current environment, unless it is overridden by using the
--env flag. All of the `coco env <cmd> <env>` commands still require the
explicit passing of an environment which seems reasonable since they are,
after all, about manipulating environments.
As part of this, I've overhauled the aging workspace settings cruft,
which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
|
|
|
if display == curr {
|
|
|
|
display += "*" // fancify the current environment.
|
|
|
|
}
|
|
|
|
fmt.Printf("%-20s %-48s %-12s\n", display, lastDeploy, resourceCount)
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
2017-03-07 14:47:42 +01:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}),
|
2017-02-26 22:06:33 +01:00
|
|
|
}
|
|
|
|
}
|