[build]: add branch and release tag in sonic_version.yml

[lguohan]

- Why I did it
the branch refers the branch name, for example
master, 202012, 201911, ...

- How I did it
will modify 'show version' command to output this as well.

- How to verify it
example for master branch

build_version: 'master.602-6efc0a88'
debian_version: '10.7'
kernel_version: '4.19.0-9-2-amd64'
asic_type: vs
commit_id: '6efc0a88'
branch: 'master'
release: 'none'
build_date: Tue Dec 29 06:54:02 UTC 2020
build_number: 602
built_by: johnar@jenkins-worker-23

example for 202012 release branch

build_version: '202012.602-6efc0a88'
debian_version: '10.7'
kernel_version: '4.19.0-9-2-amd64'
asic_type: vs
commit_id: '6efc0a88'
branch: '202012'
release: '202012'
build_date: Tue Dec 29 06:54:02 UTC 2020
build_number: 602
built_by: johnar@jenkins-worker-23

- Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[yxieca]

The tag will contain the local branch name from where the image was built. This works for release images but not for dev builds.

For instance, if I do "git checkout -b foo master", and build from branch foo, the release tag will show 'foo'.

$(basename $(git config branch.$(git rev-parse --abbrev-ref HEAD).merge)) will show upstream branch name, this one has a better chance of being correct.

[lguohan]

then, we should explicitly check-in a file and use that to derive the release tag. then, as long as user on this branch, they will be consistent on which branch they are in. the master branch will always have release tag 'master' and for each release branch, we will change that file to add a tag name there.

[jleveque]

The tag will contain the local branch name from where the image was built. This works for release images but not for dev builds.

For instance, if I do "git checkout -b foo master", and build from branch foo, the release tag will show 'foo'.

But is this a bad thing? Doesn't it make sense that if you're working on a dev branch that you renamed locally, you would probably want that branch name to show up in the build, no?

[yxieca]

The tag will contain the local branch name from where the image was built. This works for release images but not for dev builds.
For instance, if I do "git checkout -b foo master", and build from branch foo, the release tag will show 'foo'.

But is this a bad thing? Doesn't it make sense that if you're working on a dev branch that you renamed locally, you would probably want that branch name to show up in the build, no?

Depending on the purpose of this tag. I believe this tag is intended for people to distinguish what upsteam branch it is built from so that the test behavior could be tailored to accordingly.

[yxieca]

The tag will contain the local branch name from where the image was built. This works for release images but not for dev builds.
For instance, if I do "git checkout -b foo master", and build from branch foo, the release tag will show 'foo'.

But is this a bad thing? Doesn't it make sense that if you're working on a dev branch that you renamed locally, you would probably want that branch name to show up in the build, no?

Generally, when I name a branch, I name it according to what I intended to do, not where it come from (e.g. 201911, 202012). But what decides the test behavior is where it come from (201911, 202012). Oh, I replied twice :-)

[lguohan]

ok, here is what I am going to do, I am going to rename it as branch, and then I am going to add a tag file called release.

[lguohan]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[dgsudharsan]

@lguohan This is required for 202106