Skip to main content

Runtime Configuration

Configuration for the CLI can be performed in several ways:

  • On the command line

  • Using environment variables

  • Using a configuration file (YAML or JSON)

When using a configuration file it is possible to setup more than one project.

Settings

The following tables show the configuration options that are available at the root level and the command level.

Global Options

The following options can be applied to any command within the Stacks CLI.

OptionEnvironment VariableDescriptionDefaultOptions
-c, --configAMIDOSTACKS_CONFIGPath to the configuration file to use
-l, --loglevelAMIDOSTACKS_LOG_LEVELLevel of logging to be usedinfodebug, info, warning, error, fatal
-f, --logformatAMIDOSTACKS_LOG_FORMATOutput type of the loggingtexttext, json
--logcolourAMIDOSTACKS_LOG_COLOURState if logging should include colour
--logfileAMIDOSTACKS_LOG_FILEWrite all logs to the specified file
-w, --workingdirectoryAMIDOSTACKS_DIRECTORY_WORKINGDIRDirectory that the projects should be created in${PWD}
--tempdirAMIDOSTACKS_DIRECTORY_TEMPDIRDirectory to be used by Stacks for its temp filesSystem temp directory
--nobannerAMIDOSTACKS_OPTIONS_NOBANNERDo not display the Stacks banner when running the commandfalse
--nocliversionAMIDOSTACKS_OPTIONS_NOCLIVERSIONDo not perform a version check for the latest version of the Amido Stacks CLIfalse

Global Options

Scaffold Options

Scaffold Options
OptionEnvironment VariableDescriptionDefaultOptions

-n, --name

AMIDOSTACKS_PROJECT_NAME

Name of the project to create

--sourcecontrol

AMIDOSTACKS_PROJECT_SOURCECONTROL_TYPE

Source control system to be used

github

-u, --sourcecontrolurl

AMIDOSTACKS_PROJECT_SOURCECONTROL_URL

URL to the remote repository

--projectsettingsfile

AMIDOSTACKS_PROJECT_SETTINGSFILE

Each project will have its own stackscli.yml file, however this can ber overridden with a path to a different file using this option

null

-F, --framework

AMIDOSTACKS_PROJECT_FRAMEWORK_TYPE

The framework that is to be used

dotnet, java, nodejs

-O, --frameworkoption

AMIDOSTACKS_PROJECT_FRAMEWORK_OPTION

The sort of project to be created

webapi, cqrs, events

-V, --frameworkversion

AMIDOSTACKS_PROJECT_FRAMEWORK_VERSION

The version of the Amido stacks project to use.

This can be a version, a tag, a SHA ref or a branch.

latest

--frameworkprop1

AMIDOSTACKS_PROJECT_FRAMEWORK_PROPERTIES_PROP1

Properties that need to be set to allow the scaffolding to run the correct command

The project settings file will be defined by the project maintainers, but will may specify that a property needs to be set.

--frameworkprop2

AMIDOSTACKS_PROJECT_FRAMEWORK_PROPERTIES_PROP2

--frameworkprop3

AMIDOSTACKS_PROJECT_FRAMEWORK_PROPERTIES_PROP3

--frameworkprop4

AMIDOSTACKS_PROJECT_FRAMEWORK_PROPERTIES_PROP5

--frameworkprop5

AMIDOSTACKS_PROJECT_FRAMEWORK_PROPERTIES_PROP5

-P, --platformtype

AMIDOSTACKS_PLATFORM_TYPE

Platform being deployed to

aks

-p, --pipeline

AMIDOSTACKS_PIPELINE

Pipeline being used to build the project

azdo

-C, --cloud

AMIDOSTACKS_CLOUD

Cloud platform being used

azure, aws, gcp

-R, --cloudregion

AMIDOSTACKS_CLOUD_REGION

Region that the project will be deployed to

-G, --cloudgroup

AMIDOSTACKS_CLOUD_GROUP

Group in the cloud platform that will hold all the resources

--company

AMIDOSTACKS_BUSINESS_COMPANY

Name of your company or organisation

-A, --area

AMIDOSTACKS_BUSINESS_DOMAIN

Area of the company that is responsible for the project

--component

AMIDOSTACKS_BUSINESS_COMPONENT

Component of the overall project

--tfstorage

AMIDOSTACKS_TERRAFORM_BACKEND_STORAGE

Name of the storage account being used for the state

--tfgroup

AMIDOSTACKS_TERRAFORM_BACKEND_GROUP

Group name of the storage account

--tfcontainer

AMIDOSTACKS_TERRAFORM_BACKEND_CONTAINER

Container being used to store the data

-d, --domain

AMIDOSTACKS_NETWORK_BASE_DOMAIN_EXTERNAL

External domain root to be used for the projects

--internaldomain

AMIDOSTACKS_NETWORK_BASE_DOMAIN_INTERNAL

Internal domain root to be used for projects.

If not specified then the internal domain will be inferred from the external by replacing the TLD with internal. Thus if mydomain.com is provided as the external domain then the internal will be set to mydomain.internal.

--cmdlog

AMIDOSTACKS_OPTIONS_CMDLOG

Create a log file of all the commands that have been run during the scaffold process

The command log is create in the current directory with the filename cmdlog.txt

false

--dryrun

AMIDOSTACKS_OPTIONS_DRYRUN

Perform a dry run of the scaffold process. Useful for checking that things will be setup as required. No operations will be performed on the machine when run in this mode

false

--settingsfile

AMIDOSTACKS_SETTINGSFILE

Name of the file to look for in the project

stackscli.yml

--cmdlog

AMIDOSTACKS_CMDLOG

Generate a log of all the commands that the CLI has run.

The cmdlog.txt file is created in the directory that the CLI has been run in.

false

--dryrun

AMIDOSTACKS_DRYRUN

Perform a dryrun of all the CLI. Particularly useful when used with --cmdlog

false

--save

AMIDOSTACKS_SAVE

If using the interactive or command line mode for configuring the CLI, the given configuration can be saved to a file. This allows the configuration to be replayed again at a later date.

The configuration is saved to stacks.yml in the specified working directory

false

--nocleanup

AMIDOSTACKS_NOCLEANUP

Do not perform cleanup operations after the scaffoling has been completed

false

--force

AMIDOSTACKS_FORCE

This is a destructive operation

By using force the CLI will delete any projects, of the same name, that already exist in the working directory and then create the new project in its place.

It will also continue to run if the command version checks fail. For example if the project calls for dotnet version 3.1 and you have 5.0.303, the CLI would not normally continue, but with force this will be ignored and the process will continue.

false

Command Log Format

If the command log has been enabled, using --cmdlog, a file with all the commands that have been run during the scaffolding operation will be generated. The format of this file is as follows:

[<DIR>] <CMD> <ARGS>

The \<DIR> shows in which directory the command has been run in. Please note that this directory may have been deleted after the CLI has been run as it was temporary.

The \<CMD> and \<ARGS> show the command that was run and the arguments that were passed to it.

Note

On Windows based machines the \<CMD> will be prefixed with cmd /C which tells the CLI how to run the command. PowerShell has not yet been used as it is easy to customise the shell and those customisations may cause the CLI to fail when running the commands.

Configuration File

The following shows an example of a configuration file that can be passed to the command.

CLI Configuration File.

project:
- name: tigerfest
framework:
option: webapi
version: latest
platform:
type: aks
sourcecontrol:
type: github
url: https://github.com/russellseymour/my-new-project.git

pipeline: azdo

cloud:
platform: azure
region: ukwest
group: a-new-resource-group

business:
company: MyCompany
domain: core
component: infra

terraform:
backend:
storage: adfsdafsdfsdf
group: Stacks-Ancillary-Resources
container: tfstate

network:
base:
domain:
external: mydomain.com

log:
level: info

options:
cmdlog: false
dryrun: false

stacks:
dotnet:
webapi:
url: https://github.com/amido/stacks-dotnet
trunk: master

Note that when using the configuration file it is possible to specify multiple projects to be configured. This allows several projects to be setup at the same time, without having to run the command multiple times. Each project will be created within the specified working directory.

If this file was called conf.yml the command to run to consume the file would be:

.\stacks-cli.exe scaffold -c .\local\conf.yml