Comments (16)
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!
from azuretre.
- 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.
- I imagine the
GitHub
is meant toGit
in general. Where is that sourced from? Does it take into account the deployment repo?
I'm fine either way.
from azuretre.
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.
from azuretre.
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?
from azuretre.
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?
from azuretre.
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 :-)
from azuretre.
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?
from azuretre.
Hi @tamirkamara
- 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.
- I imagine the
GitHub
is meant toGit
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).
from azuretre.
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.
from azuretre.
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:
from azuretre.
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...
from azuretre.
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?
from azuretre.
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.
from azuretre.
from azuretre.
@martinpeck like that, maybe could be done as part of this - #2851 in say a customisable footer.
from azuretre.
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.
from azuretre.
Related Issues (20)
- Troubleshooting Azure CycleCloud Deployment Steps HOT 12
- Migrate GitHub CI subscription HOT 3
- Update GitHub Actions Documentation for Azure TRE
- Create New Page "GitHub PR Bot Commands" in Azure TRE Documentation
- Unrestricted & Airlock Import Review workspace versions HOT 4
- Python 3.8 out of support from October 2024, move python version to newer version
- Resource processor fails to deploy first workspace on fresh TRE deployment HOT 9
- 'Service Bus Namespace' Continues Running Even After `$ make tre-stop` HOT 7
- Custom domain configuration? HOT 3
- How to access MySQL service from VM in workspace? HOT 3
- Create MySQL Workspace Service Documentation
- Access to shared storage from Linux VM in workspace? HOT 6
- Improve Airlock Notifier Emails HOT 1
- Cost optimisation - Firewall Basic SKU HOT 7
- 'App Service' Azure Resources Remains Active After `$ make tre-stop` Command HOT 2
- Prep for Release v0.18.0
- Access to shared storage from Windows VM in workspace? HOT 1
- Azure SQL Workspace Service
- for Guacamole VMs, the 'Stop' and 'Disable' button semantics are not clear.
- httpx.ConnectTimeout: _ssl.c:1118: The handshake operation timed out HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from azuretre.