Show TRE version & deployment time in UI status bar

[jonnyry]

Description

As a TRE Administrator/Azure TRE Developer, I want to see the TRE version (Git repo + branch or tag ref + hash) and the deployment time in the status bar, So that I can easily determine the currently running version when working with multiple deployments.

Suggested UX

Acceptance criteria

TBC

---

Views welcome :-)

[marrobi]

I'm supportive of this, can't think of any reason why an organisation would not want it show.

@martinpeck @tamirkamara @damoodamoo and thoughts? Just want to check I'm not missing anything!

[tamirkamara]

1. Although I don't have a definite argument of why those are sensitive and/or shouldn't be shown, I think the question to ask is why would a normal user need all these details.
2. I imagine the GitHub is meant to Git in general. Where is that sourced from? Does it take into account the deployment repo? I'm fine either way.

[martinpeck]

Do we have all of that information somewhere within the API to be able to surface it in the UI?

My only thoughts on this are how useful it is. For example, we know that the various services in the TRE all have their own version numbers. So, is this the version of the core, the UI, or something else? Could the versions of those other things change independently of the github ref?

Also, as @tamirkamara says, some users are deploying from Azure DevOps repos, or from private repos. The existence of those repos might not be something that should be published.

[martinpeck]

Other random thoughts: would branches within those git repos confuse things too? Would a PR branch or a CI branch look different in this UI?

Given the audience (developer and admin...and, maybe, someone in support asking the user to give them some version info) would this be better off as a hidden/separate page in the UI, or simply as an API endpoint that returned the values as JSON? TBH...it will need an API endpoint anyway, so step 1 is probably making sure that we have somewhere that has all the useful version info available to the appropriate user roles.

None of these comments are to suggest it's a bad idea, but I want to make sure it makes sense beyond a manual single-instance deployment, and that it works for situations where dev, test, staging, and prod environments might all have the same repo/hash etc. Other than the URL, would I expect this UI to change?

[marrobi]

Some of the data is stored in tags so should be relitively straightforward to surface via an API.

Maybe an API endpoint that surfaces tags on a resource group?

[tamirkamara]

Some of the data is stored in tags so should be relatively straightforward to surface via an API.

I'm not sure the API identity has permission for that. Even if it does - it shouldn't :-)

[martinpeck]

Presumably you'd want this info to be stored in CosmosDB in some way, so that the API could grab it from there, as some sort of deployment record.

The scripts performing the deployment would be responsible for updating the record (or calling an API to update the record, or to add an additional record into the collection). This would also allow the metadata related to a deployment to be extended.

Do we have anything like that today that could be extended?

[jonnyry]

Hi @tamirkamara

1. Although I don't have a definite argument of why those are sensitive and/or shouldn't be shown, I think the question to ask is why would a normal user need all these details.

It depends on the definition of normal user - a researcher, probably not. But an administrator, developer, engineer - I think its useful to be certain on the version of the TRE running when developing/deploying/troubleshooting.

Perhaps all the fields aren't necessary or they could be combined into a single "build tag" / "product version" (e.g. BUILD_TAG = ORG/REPO + BRANCH/TAG/PR + HASH + DEPLOY_TIME) - essentially what I am trying to capture in the request is the ability to pinpoint back to the code exactly which version is running.

2. I imagine the GitHub is meant to Git in general. Where is that sourced from? Does it take into account the deployment repo?

Yes, in terms of UI labels, GitHub could be changed for Git instead.

Deployment repo - good question. The deployment repo does complicate things in terms of implementation - having seperate code to determine the correct git metadata when running from the deployment repo - but also whether we also want to surface any of the deployment repo values themselves (given user defined templates are added to the build as part of the deployment repo).

[jonnyry]

Hi @martinpeck

My only thoughts on this are how useful it is. For example, we know that the various services in the TRE all have their own version numbers. So, is this the version of the core, the UI, or something else? Could the versions of those other things change independently of the github ref?

The Azure TRE overall product version. This ideally would be a single version, e.g. v0.15.2 - however given deployments can occur from different branches/tags/PRs, and indeed different forks altogether - I ended up with four separate fields.

Also, as @tamirkamara says, some users are deploying from Azure DevOps repos, or from private repos. The existence of those repos might not be something that should be published.

Good point, perhaps the concept needs to be abstracted into something like a single BUILD_TAG field which can be customised/populated based on the source control + CICD platform being used.

[jonnyry]

Other random thoughts: would branches within those git repos confuse things too? Would a PR branch or a CI branch look different in this UI?

None of these comments are to suggest it's a bad idea, but I want to make sure it makes sense beyond a manual single-instance deployment, and that it works for situations where dev, test, staging, and prod environments might all have the same repo/hash etc. Other than the URL, would I expect this UI to change?

Agreed. Perhaps adding the environment name in somewhere might be useful also.

Here's an example of a deployment from a feature branch of a (our) fork:

[tamirkamara]

Presumably you'd want this info to be stored in CosmosDB in some way, so that the API could grab it from there, as some sort of deployment record.

The scripts performing the deployment would be responsible for updating the record (or calling an API to update the record, or to add an additional record into the collection). This would also allow the metadata related to a deployment to be extended.

Do we have anything like that today that could be extended?

Unfortunately we don't have something like this. It's also tricky to update the DB from the deployment agent as it's vnet approved only...

[jonnyry]

Presumably you'd want this info to be stored in CosmosDB in some way, so that the API could grab it from there, as some sort of deployment record. The scripts performing the deployment would be responsible for updating the record (or calling an API to update the record, or to add an additional record into the collection). This would also allow the metadata related to a deployment to be extended. Do we have anything like that today that could be extended?

Unfortunately we don't have something like this. It's also tricky to update the DB from the deployment agent as it's vnet approved only...

Rather than making available via the API, could it be injected into the ui/app/src/config.json file as part of the build, similar to the way the existing UI component version is?

[marrobi]

I think I would do it by adding environment variable(s) on the web app. Can get the repo details and either pass them into the TF or maybe use local exec. Then return them via an API.

[martinpeck]

If you’re going down this route, maybe just allow a custom string to be passed into the build and deployment and display this string in the UI, and allow each customer to decide what they want to put into that string, and how to construct the string?

Eg I might simply have “mpeck” while someone else might write their own script to generate the string “main-v123-1.6.0”.

This way we can avoid exposing anything that a given customer doesn’t want exposed, avoid having to harvest these values from multiple sources, and it’s a very clear and explicit “opt in”

Regards, Martin

---

From: Marcus Robinson @.> Sent: Friday, December 15, 2023 11:25:48 AM To: microsoft/AzureTRE @.> Cc: Comment @.***> Subject: Re: [microsoft/AzureTRE] Show TRE version & deployment time in UI status bar (Issue #3809)

I think I would do it by adding environment variable(s) on the web app. Can get the repo details and either pass them into the TF or maybe use local exec. Then return them via an API.

— Reply to this email directly, view it on GitHubhttps://github.com/microsoft/AzureTRE/issues/3809#issuecomment-1857720793 or unsubscribehttps://github.com/notifications/unsubscribe-auth/AALUFY3W2B2FN2YRINBDPA3YJQXT3BFKMF2HI4TJMJ2XIZLTSSBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLAVFOZQWY5LFVIZTAMZWGAZDSNJYGKSG4YLNMWUWQYLTL5WGCYTFNSWHG5LCNJSWG5C7OR4XAZNMJFZXG5LFINXW23LFNZ2KM5DPOBUWG44TQKSHI6LQMWVHEZLQN5ZWS5DPOJ42K5TBNR2WLKJTGQ2DKMJRGI3DHAVEOR4XAZNFNFZXG5LFUV3GC3DVMWVDEMBTGUZTAMJVGAZIFJDUPFYGLJLMMFRGK3FFOZQWY5LFVIZTAMZWGAZDSNJYGKTXI4TJM5TWK4VGMNZGKYLUMU. You are receiving this email because you commented on the thread.

Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[marrobi]

@martinpeck like that, maybe could be done as part of this - https://github.com/microsoft/AzureTRE/issues/2851 in say a customisable footer.

[jonnyry]

If you’re going down this route, maybe just allow a custom string to be passed into the build and deployment and display this string in the UI, and allow each customer to decide what they want to put into that string, and how to construct the string? Eg I might simply have “mpeck” while someone else might write their own script to generate the string “main-v123-1.6.0”. This way we can avoid exposing anything that a given customer doesn’t want exposed, avoid having to harvest these values from multiple sources, and it’s a very clear and explicit “opt in”

@martinpeck This sounds ideal.