junminahn
commented
1 day ago I’ve reviewed this, and while it's an interesting concept, I don’t think it’s feasible to implement in the registry app. The registry is specifically focused on maintaining products on OpenShift clusters and public cloud products, not GitHub repositories. Many applications are deployed on-premise with their codebases in GitHub, and there are also many repositories hosted on other source control platforms like Bitbucket.
Hi Olena!
I have an idea (or two) for the platform registry product that I think would help us all out long term. Including Om because internally our Ministry is looking at solutions for similar issues.
High level summary - have drop down for ministry building the service, one for ministry it serves, and a list field for repos. Nice to have - add a webhook to tag the repos with that information so it's queryable via the github API (and viewable in web when looking at repo). I put a detailed breakdown of what/why below for whoever might explore it.
Cheers,
M
Detailed description for UX/devs:
Right now in the platform registry form there is just one drop down field for Ministry (and also it is out of date, WLRS isn't on there).
I think what would be way better is one drop down for the Ministry that the digital product or service operates under/serves, and another drop down for the Ministry that is building it. As is often the case they aren't going to be the same.
It also doesn't have a place to list the repo(s) for the product namespaces. I think this is critical information to keep next to the namespaces and contacts. In example of a bad vulnerability affecting may bcgov repos, we'd be able to query github code and the registry and know what namespaces were impacted and have contacts. A good tool for MISOs.
Where I think this would get even better is by using automation (github API) to apply topics to repos indicating they have a namespace set, what ministry built them, and what ministry they serve. Then all this stuff is queryable with the github API for anyone with org access.
Example use case - I work for WLRS and I want to find all the repos that are: Still in use Have been built by WLRS but not necessarily owned/used by WLRS (meaning our devs are working on them) Have dockerfiles indicating I have devs that may need to get on my enterprise license If things were implemented as suggested, I could write a graphQL query to return just the list of repos relevant to my criteria above. If we tagged the repos with some pointer to the platform registry record, then with appropriate access or a request to you guys I could find the contacts as well and update them if needed.
As of today I can use the graphql API to find all bc gov org repos that have dockerfiles, but I can't narrow it down further than that because we don't tag/topic repos with who built them and who they serve. Additionally, the project registry db, even if I reached out to you guys to query it, will only show the ministry that the product serves OR the one that built it (depends on who filled the form), won't have the repos, and so I have to fish through my ministries confluence pages etc and compare what I see on readmes, possibly missing some repos that were created after the fact.
Food for thought!
Micheal Wells Chapter Lead, Full Stack Development Development & Digital Services NRIDS | Ministry of Water, Land and Resource Stewardship micheal.w.wells@gov.bc.ca W: (250) 312-7310 | C: (250) 319-7748