Multiple projects, same webhook integration

[gespi1]

Hi Devlake Team, we use Argocd for deployments and are sending webhooks to Devlake per deploy and i am separating projects by individual repos. I have two projects, for two repos, configured like so; github config is set on each project and is scoped to their respective repo. However they both use the same webhook integration (argocd). Do you know if devlake is smart enough to split the deployments on each project based on the repo_urls from the webhook payloads?

The current result is that i go the dashboard and the results for project 1 and project 2 are the same. Meaning to me that devlake is considering all data within a webhook integration to be part of the project regardless of the repo_url. Our repo_urls end in .git (https://github.com/org/repo.git) if that matters.

Thank you for your responses in the meantime. ty

[klesh]

Which dashboard and chart exactly?

[gespi1]

currently only using the DORA dashboard

[gespi1]

Using the DORAdebug dashsboard, you can see both projects have matching deployment_count and both use webhook:1

Also on the same dashboard it looks like the whatever webhooks are from webhook:1 are considered part of the project

[gespi1]

going to switch to using webhook per project

[klesh]

I may work for some metrics, but not all depends on the implementation of the metric.
I would suggest you create multiple webhooks for better flexibility.

[gespi1]

@klesh what about introducing scopes for deployment webhooks. Could we scope based on repo_url? Just like every other integration we can have a scope on webhooks so they behave like all other integrations. That way we can have more control over what webhooks go to which projects instead of configuring a webhook per project which adds some overhead when configuring a new project.

[klesh]

@gespi1 I would love to introduce scopes for webhooks to make them behave like other integrations.
However, I don't understand why it would make it easier to configure a new project. One would have to create multiple scopes and add them to projects instead as well.
cc. @Startrekzky

[gespi1]

Take github for example we create one integration, select the integration per project and then scope out which repos belong to a project. On the other hand webhooks would need a new integration for every project. Adding extra steps of configuring a new webhook endpoint and then adding that new url within our pipelines/notification configs. Why can we not have webhooks follow the same model?

This would actually make more sense in terms for shared projects as well. If teams share projects, instead of having two webhook integrations, it'll just be one integration with each project scoping to the shared repos.

[klesh]

Sounds reasonable to me, @Startrekzky What do you think?

[Startrekzky]

@gespi1 @klesh I'm open to introducing data scope to webhooks. However, I don't think this change will solve the shared projects problem, as webhooks can only distinguish deployments and incidents from shared projects, not PRs or commits, while DORA requires all these four entities to calculate.

@gespi1 My question is how the introduction of data scope will simplify the configuration of a single webhook with different repo values compared with the configuration of multiple webhook endpoints in your data source.

[gespi1]

• having fewer integrations to manage simplifies the overall maintenance
• centralizing webhook endpoints at devlake.example.org/webhooks rather than assigning specific URLs for each project can significantly reduce the complexity of CD environment provisioning.
• the current approach of configuring separate webhook URLs for each project introduces an additional layer in the automation workflow.
  Requiring the knowledge of webhook URLs before provisioning/configuring CD environments can be a potential bottleneck and prerequisite, affecting the integration of new project

Once your integrations are inplace it should be all about composing projects. While scoping might not be the only solution the concept of pooling together webhook data and integrating and projects filtering it may be worth exploring.

[Tomer20]

+1

Also using ArgoCD, and managing multiple webhooks with multiple secrets seems unreasonable. Too much ops.
Can we introduce a "project" key in the deployment API, so we can easily associate a deployment with the webhook call?