[Question][config-ui] Domain type selection UI for Azure devops external repositories

[CamilleTeruel]

Currently, the config-UI let user select one set of domain types for all scopes. This is enough for the majority of cases and the UI is simple.
However, there are some cases where one domain type makes sense for one scope but not for another. The question is how to handle this in the UI.

One example is with azure devops plugins. In this plugin, a scope corresponds to
a repository and it supports two domain types: CICD and CODE_REVIEW.
Right now, it only support repositories hosted in azure devops. But we have users who use azure CICD server for repositories hosted elsewhere, so we'd like to support them soon.

The UI issue is that the user can only select one set of domain types for all selected scopes. But in this case, the CODE_REVIEW domain type does not make sense for external repositories. So if the user selects some internal repositories and some external ones, the user can select CODE_REVIEW but it will won't apply to external repositories. If the user selects only external repositories, that domain type will be totally ineffective.

The question is whether the UI should let the user know that some domain types are not available on some scope.

One way to let bring this information to the front-end is to include a set of available domain types to each scope returned by the remote scopes endpoint.

Then there are several things we can do to adapt the UI:

• gray out the domain types that are not available for any of the selected scopes
• decorate the domain types that are available for some selected scopes but not for others
• show which domain types are available on a given scope, for example with a tooltip on hover or as small icons depicting the domain types next to each scope

So what do you think? Is this an issue worth considering? If so, what do you
think is the best way to handle it? Should we find a generic UI that handles
this case or should we handle it only in Azure devops plugin? How likely is it that current and future plugins will have a similar issue?

[yumengwang03]

Got it, I'll work on a UI solution for this. I have a question: if the user selects external repositories (let's say some GitHub repos), do we retrieve the external repo info from the Azure DevOps API, or the user has to also create a GitHub connection so that we can get this info? If the former is correct, can we distinguish between Azure DevOps native repos and external repos? @CamilleTeruel

[Startrekzky]

My opinions:

1. Whether we should support these Azure CICD deployments from external repos?
   Yes, If the use case does exist, which means users have to collect the CICD data triggered by external repos to measure DORA metrics by DevLake.

2. How I understand this phenomenon from the product level.
   I treat Azure Pipeline as an independent CI/CD tool. That's why it enables 'triggering' from external repos just like Jenkins does. Actually, I'm curious if GitLab CI shares the same problem.

3. How should we tackle it?

• Option 1 - Divide Azure DevOps to Azure Repos and Azure Pipeline: I guess no one wants this way.
• Option 2 - Add external data scope to the option list of 'setting data scope for an Azure connection', other configuration stays the same. If users
  • only select internal Azure repos: everything stays the same
  • select one or more external Azure repos: users cannot remove 'CICD domain' in the Data Entities configuration. Since the external repos are not collected by DevLake, the cicd_scope_id from external Azure repos can be marked as the repo's own unique identifier.

4. What's the urgency?
   I won't treat it as an urgent problem until 3+ users bring it to us on GitHub or Slack.

@CamilleTeruel @hezyin @klesh @yumengwang03

[klesh]

Could the external repositories be hosted in Github/Gitlab and other platforms?
The way I see it, Selected Domain Types mean users would like to collect them IF they are available, not necessarily mean we must collect them.
Even for Github/Gitlab, users may disable Github Action/Pipeline and we have no way to determine that.
For simplicity's sake, I suggest that users should add those external repositories as part of the project.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity for 30 days. It will be closed in next 7 days if no further activity occurs.

[hezyin]

Closing this discussion now as there's a new issue tracking the implementation.