Open davidediruscio opened 4 years ago
@mhow2 I really understand the need for an issue tracking mechanism to manage the scava's issues. However, I think that having a README
file in the scava-deployment
repository containing all these details and providing an efficient traceability of the current docker components status would be worthy than placing it on admin-ui as it's a part of the integration process.
I'm unsure it's a good idea to close that one. And I don't understand how your previous comment fits to the subject @ambpro. Anyway, if the software gets into a beta testing campaign, versioning & proper release management is something you'll need to add.
Hi @mhow2, Sorry for the misunderstanding. As we talk before on #slack, the current crossminer's components didn't follow any versioning management through the development life cycle. Regarding to the beta testing campaign discussed on the last meeting, please feel free to reopen it whenever you want to discuss this subject.
I'm going to reopen this issue. It looks essential to me to have a commit hash reference of the metric-platform build somewhere if we want an efficient workflow in bug fixing and release strategy. It looks very obvious to me. Please @davidediruscio can you provide your input on this.
I created a pull request on Scava-deployment repository with some new functionalities, including the capability of listing the commitID of the SCAVA software deployed in Docker images.
Anyone interested is invited to see https://github.com/crossminer/scava-deployment/pull/96 and provide some feedback.
Thanks
As I have suggested in the mailing list, I think that at some point, having the commit id, build id, or a version number would benefit in the testing and to have accurate issue report. Can save some time when someone take a look at fixing/triage issues too.
So, what do you think having all the instance's components versions displayed somewher in the admin UI ?