Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform registry idea(s) #3732

Open
Iryna-Kaplun opened this issue Sep 11, 2024 · 2 comments
Open

Platform registry idea(s) #3732

Iryna-Kaplun opened this issue Sep 11, 2024 · 2 comments

Comments

@Iryna-Kaplun
Copy link
Collaborator

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
[email protected]
W: (250) 312-7310 | C: (250) 319-7748

@junminahn
Copy link
Collaborator

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.

@Iryna-Kaplun
Copy link
Collaborator Author

Luke will reach to Micheal Wells to explain that this will take us a little while to make a decision on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants