Environment: WSL2 Ubuntu

Issue: When using bedrock setup, bedrock setup stalls on info: attempting to login to az command line. Using the -v or --verbose tag shows that the az login output directs the user to sign in using a web browser, providing a URL and a login code.

Resolution: Propagate this output to the user, if for some reason the az login command can't bring up a browser to login.

Other Resolution: Fix the WSL2 issue of not being able to open a browser.

I get the following error

$ bedrock setup
error:   
code: 1000
message: setup-cmd-failed: Setup command was not successfully executed.
  code: 1010
  message: setup-cmd-az-cli-err: az command line was not installed.
  details: ERROR: az: 'version' is not in the 'az' command group. See 'az --help'.

I'm using az version 2.0.72

$ az --version
azure-cli                         2.0.72 *
command-modules-nspkg               2.0.3
core                              2.0.72 *
nspkg                              3.0.4
telemetry                          1.0.3 *
Extensions:
aks-preview                       0.4.14
azure-devops                      0.12.0
Python location '/usr/local/Cellar/azure-cli/2.0.72/libexec/bin/python'
Extensions directory '/Users/andrebriggs/.azure/cliextensions'
Python (Darwin) 3.7.4 (default, Jul  9 2019, 18:13:23) 
[Clang 10.0.1 (clang-1001.0.46.4)]
Legal docs and information: aka.ms/AzureCliLegal
You have 3 updates available. Consider updating your CLI installation.

The work around appears to be to have a new version of az that supports az version

As a: developer

I want: The bedrock-cli to be made available via NPM

So that:

• I can more easily install the bedrock-cli locally and on agents which already have Node.js installed -- this will also make installation cleaner as you can run npm install -g bedrock-cli@<some>.<semver>.<version> and have it automatically added to the PATH (and not require to download a large binary containing the entire Node.js binary)
• I can more easily publish new releases using yarn publish, which will automatically create a release tag, push it to npm, and give the ability to push that tag back up to github.

Describe the solution you'd like:

• Publish an NPM module for bedrock-cli

Acceptance Criteria:

• Find out how we can add an npm module to the microsoft NPM org
• Add an bin to the package.json that points to either a wepback compiled version of bedrock.js or if compiled with tsc, point to the index.js mapping to src/index.js
• Push a release

Describe alternatives you've considered:

Additional context:

Does this require updates to documentation?: yes

when i run bedrock setup i get

error:   
code: 1000
message: setup-cmd-failed: Setup command was not successfully executed.
  code: 1010
  message: setup-cmd-az-cli-err: az command line was not installed.
  details: spawn az ENOENT

PS C:\code\flash-hld> az --version
azure-cli                          2.7.0
command-modules-nspkg              2.0.3
core                               2.7.0
nspkg                              3.0.4
telemetry                          1.0.4
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\[My Username]\.azure\cliextensions'

We can thus see that Bedrock isn't finding the Az CLI

I think this is an issue with how the command is called in Node -- https://stackoverflow.com/questions/27688804/how-do-i-debug-error-spawn-enoent-on-node-js

I want to be able to specify ring-level configuration for my service's chart within its bedrock.yaml file

So that the developer in control of each service has more direct control over their own service's environment-specific configuration.

It would look like this:

And would have the same effect as going to the HLD repo and running the command
fab set --subcomponent project_name.service_name.ring_name.chart replicaCount=2

I believe this would be a very logical evolution for the usability of ring-level configuration.

Thanks for your time.

Look at short flags in https://microsoft.github.io/bedrock-cli/commands and

• See if we have consistency amongst commands
• If not, propose an updated short flag name references
• Codify these short flag names in documentation

For example, some commands have a short flag -p for --project and others have no short flag.

An effort was started in the past but is out of date here.. Use https://microsoft.github.io/bedrock-cli/commands as the source of truth

A command option should have same the same short flag and multi-word name across all CLI commands to be consistent.

Does this require updates to documentation?:
YES!

As a:
User

I want:
To install bedrock tools with homebrew

So that:
It's easier to install dependencies, and manage versions

Describe the solution you'd like:
Support installing bedrock-cli and fabrikate via homebrew

Acceptance Criteria:

• Design doc.
• Create homebrew formula repository https://github.com/microsoft/homebrew-bedrock
• Add bedrock-cli formula to /microsoft/homebrew-bedrock -> PR
• Reuse formulas from this repository: https://github.com/edaena/homebrew-core/
• Update versions and dependencies for the formulas to reflect the latest
• Investigate a way of automatically updating formulas based on releases.
• Investigate using brew bottles for distributing the tools instead of having users build from source: https://jonathanchang.org/blog/maintain-your-own-homebrew-repository-with-binary-bottles/
• Solution does not require building the bedrock-cli from source
• Solution is part of the Azure DevOps release pipeline and requires no manual intervention
• Test solution in a separate Azure DevOps project
• Test additional release
• Integrate solution to the Bedrock CLI release pipeline
• Add github service connection for microsoft/homebrew-bedrock in the Azure Pipeline

Describe alternatives you've considered:

• Possibly add a step to the bedrock github release pipeline

Additional context:
Related resources:
Host bottles for taps
Maintain your own homebrew repo
homebrew bottles
Brew test bot
Example: azcli formula

Does this require updates to documentation?:

Hi.

I am trying to install bedrock-cli from homebrew on my Mac with macOS Catalina installed.
It seems your release 0.6.5 tar file is missing (https://github.com/microsoft/bedrock-cli/releases/download/v0.6.5/dist.tar.gz)

See install output below.

bash-3.2$ brew tap microsoft/bedrock
bash-3.2$ brew install microsoft/bedrock/bedrock-cli
==> Installing bedrock-cli from microsoft/bedrock
==> Downloading https://homebrew.bintray.com/bottles/terraform-0.13.3.catalina.bottle.tar.gz
Already downloaded: /Users/FJLAN/Library/Caches/Homebrew/downloads/181696da4bf09bfcc0f0be9eec1d8081adef2949f011ece68eb506c0a99b9617--terraform-0.13.3.catalina.bottle.tar.gz
==> Downloading https://homebrew.bintray.com/bottles/azure-cli-2.12.1.catalina.bottle.tar.gz
Already downloaded: /Users/FJLAN/Library/Caches/Homebrew/downloads/b28d71f04579be6f4113dbe6976a252dc6bba5f6fe39a2d8de571bfc68b78f58--azure-cli-2.12.1.catalina.bottle.tar.gz
==> Downloading https://github.com/microsoft/bedrock-cli/releases/download/v0.6.5/dist.tar.gz
#=#=#
curl: (22) The requested URL returned error: 404 Not Found
Error: Failed to download resource "bedrock-cli"
Download failed: https://github.com/microsoft/bedrock-cli/releases/download/v0.6.5/dist.tar.gz
bash-3.2$

We should utilize spinners in bedrock setup like in the animated gif below:

Currently bedrock setup will dump logs for all the underlying methods in the console. This makes sense in --verbose mode. Since setup is meant to be an introduction to bedrock GitOps pipelines showing the user what is going on at the higher level makes more sense than a debug log.

for some az cli tool, az --version returns

azure-cli                          2.5.0 *
...

as * at the end of the version number.

This causes bedrock setup unable to detect the az cli's version; and quit

First I tried setting project name to be an existing project, that didn't work.
With a new project name, I get the following error.

When clicking on the build badge I get the following:

Seems related to this external issue: https://developercommunity.visualstudio.com/content/problem/1064899/status-badge-of-build-pipeline-leads-to-404-not-fo.html

This is failing our yarn md-lint action and consequently any builds or PR builds

https://github.com/microsoft/bedrock-cli/blob/master/guides/project-service-management-guide.md

In the following line:
bedrock project create-variable-group $VARIABLE_GROUP_NAME -r $ACR_NAME -u $SP_APP_ID -t $SP_TENANT -p $SP_PASS

The variable group will always be created on bedrock's configured Project inside Azure DevOps, which may not be the correct repository for the specific project. The -d flag should be added with instruction to user to correctly specify that value.

In the following line:
bedrock project install-lifecycle-pipeline --org-name $ORG_NAME --devops-project $DEVOPS_PROJECT --repo-url $SERVICE_REPO_URL --repo-name $SERVICE_NAME

--repo-name has been removed from this command, reference to it should be removed here.

Hey there --

• Downloaded the Windows bedrock.exe
• Put it in a folder
• Added folder to path
• Open new Powershell Window

Az CLI is installed

However, when I run bedrock setup the response is:

error:   
code: 1000
message: setup-cmd-failed: Setup command was not successfully executed.
  code: 1010
  message: setup-cmd-az-cli-err: az command line was not installed.
  details: spawn az ENOENT

Upon creating the 0.6.6 release copy the homebrew install documentation from microsoft/homebrew-bedrock into this repository and the microsoft/bedrock repository.

As a:

bedrock user, but not necessarily a bedrock cli user

I want:

To be able to invoke a script to add an "hld-update" stage to existing pipelines yaml files.

So that:

I can bring my own custom build pipeline that produces a docker image pushed to a registry that I can use to update my HLD

Describe the solution you'd like:

• A tool or script that accepts a path to an azure yaml file as a parameter that simply injects a stage to the pipelines yaml that updates a bedrock HLD repository with an image tag for a newly build service.

Acceptance Criteria:

• Any such tool or script must be able to take an azure pipelines yaml file and inject a default build stage into it that will update an HLD repository. This "default" build stage does not need to be valid - and any number of warnings to let the user know of this should suffice.

The steps following are the hld update stage verbatim from fileutilts.ts in bedrock-cli:

                  `export SERVICE_NAME_LOWER=$(echo ${serviceName} | tr '[:upper:]' '[:lower:]')`,
                  `export BUILD_REPO_NAME=${BUILD_REPO_NAME(serviceName)}`,
                  `export BRANCH_NAME=DEPLOY/$BUILD_REPO_NAME-${IMAGE_TAG}`,
                  `export FAB_SAFE_SERVICE_NAME=$(echo $SERVICE_NAME_LOWER | tr . - | tr / -)`,
                  `# --- From https://raw.githubusercontent.com/Microsoft/bedrock/master/gitops/azure-devops/release.sh`,
                  `. build.sh --source-only`,
                  ``,
                  `# Initialization`,
                  `verify_access_token`,
                  `init`,
                  `helm_init`,
                  ``,
                  `# Fabrikate`,
                  `get_fab_version`,
                  `download_fab`,
                  ``,
                  `# Clone HLD repo`,
                  `git_connect`,
                  `# --- End Script`,
                  ``,
                  `# Update HLD`,
                  `git checkout -b "$BRANCH_NAME"`,
                  `export BUILD_REPO_NAME=${BUILD_REPO_NAME(serviceName)}`,
                  `export IMAGE_TAG=${IMAGE_TAG}`,
                  `export IMAGE_NAME=$BUILD_REPO_NAME:$IMAGE_TAG`,
                  `echo "Image Name: $IMAGE_NAME"`,
                  `export IMAGE_REPO=${IMAGE_REPO}`,
                  `echo "Image Repository: $IMAGE_REPO"`,
                  `cd $(Build.Repository.Name)/$FAB_SAFE_SERVICE_NAME/${SAFE_SOURCE_BRANCH}`,
                  `echo "FAB SET"`,
                  `fab set --subcomponent chart image.tag=$IMAGE_TAG image.repository=$IMAGE_REPO/$BUILD_REPO_NAME`,
                  ``,

Assuming any such build stage downloads the build.sh script that provides a number of the functions invoked above, the remaining assumption left is that any pipeline that has the build pipeline stage injected offers a number of pipeline variables for the stage to be able to invoked properly. This should be made explicit to the end user, as pipelines will differ from project to project.

Describe alternatives you've considered:

• We've considered building custom build steps directly into spk, but decided against that solution as it can become complicated, and does not

Additional context:

• Out of band request for tooling

Does this require updates to documentation?:

no

Related to microsoft/bedrock#1423

Currently we produce a AzDO pipeline yaml that looks like this:

# GENERATED WITH BEDROCK VERSION 0.6.5
trigger:
  branches:
    include:
      - master
variables:
  - group: quick-start-vg
pool:
  vmImage: ubuntu-latest
steps:
  - checkout: self
    persistCredentials: true
    clean: true
  - task: HelmInstaller@1
    inputs:
      helmVersionToInstall: 2.16.3
  - script: |-
      set -e
      # Download build.sh
      curl $BEDROCK_BUILD_SCRIPT > build.sh
      chmod +x ./build.sh
    displayName: Download bedrock bash scripts
    env:
      BEDROCK_BUILD_SCRIPT: $(BUILD_SCRIPT_URL)
  - script: |-
      set -e
      commitId=$(Build.SourceVersion)
      commitId=$(echo "${commitId:0:7}")
      . ./build.sh --source-only
      get_bedrock_version
      download_bedrock
      pullrequestid=$(az repos pr list --organization $(System.TeamFoundationCollectionUri) --project $(System.TeamProject) --status completed | jq -r --arg commitid "$(Build.SourceVersion)" '.[] | select(.lastMergeCommit.commitId | startswith($commitid))' | jq '.pullRequestId')
      if [[ -z "$pullrequestid" ]]; then
      ./bedrock/bedrock deployment create -n $(INTROSPECTION_ACCOUNT_NAME) -k $(INTROSPECTION_ACCOUNT_KEY) -t $(INTROSPECTION_TABLE_NAME) -p $(INTROSPECTION_PARTITION_KEY) --p3 $(Build.BuildId) --hld-commit-id $commitId
      else
      ./bedrock/bedrock deployment create -n $(INTROSPECTION_ACCOUNT_NAME) -k $(INTROSPECTION_ACCOUNT_KEY) -t $(INTROSPECTION_TABLE_NAME) -p $(INTROSPECTION_PARTITION_KEY) --p3 $(Build.BuildId) --hld-commit-id $commitId --pr $pullrequestid
      fi
    displayName: 'If configured, update manifest pipeline details in Spektate db before manifest generation'
    condition: 'and(ne(variables[''INTROSPECTION_ACCOUNT_NAME''], ''''), ne(variables[''INTROSPECTION_ACCOUNT_KEY''], ''''),ne(variables[''INTROSPECTION_TABLE_NAME''], ''''),ne(variables[''INTROSPECTION_PARTITION_KEY''], ''''), ne(variables[''Build.Reason''], ''PullRequest''))'
    env:
      AZURE_DEVOPS_EXT_PAT: $(PAT)
  - task: ShellScript@2
    displayName: Validate fabrikate definitions
    inputs:
      scriptPath: build.sh
    condition: 'eq(variables[''Build.Reason''], ''PullRequest'')'
    env:
      VERIFY_ONLY: 1
  - task: ShellScript@2
    displayName: Transform fabrikate definitions and publish to YAML manifests to repo
    inputs:
      scriptPath: build.sh
    condition: 'ne(variables[''Build.Reason''], ''PullRequest'')'
    env:
      ACCESS_TOKEN_SECRET: $(PAT)
      COMMIT_MESSAGE: $(Build.SourceVersionMessage)
      REPO: $(MANIFEST_REPO)
      BRANCH_NAME: $(Build.SourceBranchName)
  - script: |-
      set -e
      . ./build.sh --source-only
      cd "$HOME"/${MANIFEST_REPO##*/}
      latest_commit=$(git rev-parse --short HEAD)
      url=$(git remote --verbose | grep origin | grep fetch | cut -f2 | cut -d' ' -f1)
      repourl=${url##*@}
      get_bedrock_version
      download_bedrock
      ./bedrock/bedrock deployment create -n $(INTROSPECTION_ACCOUNT_NAME) -k $(INTROSPECTION_ACCOUNT_KEY) -t $(INTROSPECTION_TABLE_NAME) -p $(INTROSPECTION_PARTITION_KEY) --p3 $(Build.BuildId) --manifest-commit-id $latest_commit --repository $repourl
    displayName: 'If configured, update manifest pipeline details in Spektate db after manifest generation'
    condition: 'and(ne(variables[''INTROSPECTION_ACCOUNT_NAME''], ''''), ne(variables[''INTROSPECTION_ACCOUNT_KEY''], ''''),ne(variables[''INTROSPECTION_TABLE_NAME''], ''''),ne(variables[''INTROSPECTION_PARTITION_KEY''], ''''), ne(variables[''Build.Reason''], ''PullRequest''))'

Based upon information in microsoft/bedrock#1423 We should create a version of this Yaml that is templated.

As a Bedrock developer I am using and developing bedrock. After running yarn test on source code I find that my $/.bedrock/config.yaml file is replaced with this mock file

The offending test appears to config.test.ts which calls saveConfiguration to the default location ($/.bedrock/config.yaml) not a temp directory. See here

The expectations that "production" configuration doesn't get overwritten by tests. We should write to a temp directory.

Repro:

1. Use bedrock init -i to setup an config file at ~/.bedrock/config.yaml
2. Call bedrock init -i and see that the first prompt already has a value filled in for you

$ bedrock init -i
? Enter organization name
 (myOrg) 

3. Then call bedrock setup and the first prompt doesn't already have a value filled in for you

$ bedrock setup
info:    az cli vesion 2.5.1
? Enter organization name

I would expect the following

$ bedrock setup
info:    az cli vesion 2.5.1
? Enter organization name
(myOrg)