Introspection dashboard should capture correct ring name

[samiyaakhtar]

As a: developer

I want: to to view the ring name from bedrock.yaml

So that: I can introspect my services

Describe the solution you'd like:
Currently, it's a bit confusing when the branch name is x and environment name deploy/something-x because it does not clarify which one is ring and whether the branch name was a branch in source repo or HLD repo. Could do some thinking around this.

- Ring name should be derived from bedrock.yaml during the source build pipeline process

• Ring name should come from source branch name

Acceptance Criteria:
Column data makes more sense

Describe alternatives you've considered:
So far we've considered branch name to belong to source repo and environment name to belong to HLD, but there's no correct ring name.

Additional context:

Does this require updates to documentation?: No

[andrebriggs]

In the case below the ring is develop. That is what exists in the bedrock.yaml

@samiyaakhtar What does the Environment column in the dashboard above map to in the command
./spk/spk deployment create -n $(INTROSPECTION_ACCOUNT_NAME) -k $(INTROSPECTION_ACCOUNT_KEY) -t $(INTROSPECTION_TABLE_NAME) -p $(INTROSPECTION_PARTITION_KEY) --p2 $(Build.BuildId) --hld-commit-id $latest_commit --env $BRANCH_NAME --image-tag $tag_name --pr $pr_id ?

[samiyaakhtar]

@andrebriggs it maps to --env $BRANCH_NAME

[samiyaakhtar]

@andrebriggs in the case here the ring name is not develop, it's the branch in source repo that's develop. The ring name is deploy/epmt/order-store-order-service-develop-20200312.5

[samiyaakhtar]

Extracting ring name during ACR -> HLD step shouldn't need to read bedrock.yaml because ring names are stored as an array in yaml:

rings:
  master:
    isDefault: true
  deve: {}
  qa: {}
  prod: {}
services:
  ...

There’s actually no way to infer what ring maps to, during acr->hld pipeline since there's no metadata under each ring name. In fact, $(Build.SourceBranchName) should always map to a ring name in bedrock.yaml. This should heavily simplify this task to no longer involve reading bedrock.yaml.