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?

[marais-vzc]

Chiming in on this also. To expect a new webhook for every project in devlake is not workable. I'm thinking that a simple project name, or other unique id parameter on the webhook request should allow this to be solved.

[mieliespoor]

@klesh and @Startrekzky. Can this be reviewed again? In our case, we have, at the moment, around 1200 projects in Devlake. Our deployment tool is not yet supported by Devlake, meaning we need to make use of webhooks. However, with 1 webhook required per devlake project, we now need to go into 1200 projects and add a unique webhook for each. The alternative is that we add one generic webhook, and the tool add a scope or additional parameter to the data body of the request to identify which project this request applies to.

[klesh]

I see, I understand the scaling problem.
That said, I’m still a bit unclear about the solution.

We still need to distinguish webhook requests coming from your Deployment Projects and map them to the correct DevLake Projects, right?

If so, we’ll need at least one way to classify them — whether from the body, URL, or even the headers. In any case, wouldn’t you still need to configure the Deployment Tool?

I think I’ll need a few more details about the deployment tool itself and how the proposed solution works.

[mieliespoor]

In our case, we can simply add the project name to the body of the post request. We have a 1-1 relationship between the repository and the deployment project, and as a result, also a 1-1 to devlake. As a result, we could simply do a webhook post similar to this;

curl https://apache-devlake.internal.endpoint/api/rest/plugins/webhook/connections/1/deployments -X 'POST' -H 'Authorization: Bearer ' -d '{
      "id": "Required. This will be the unique ID of the deployment",
      "projectName": "devlake-project-name",
      "startedDate": "2023-01-01T12:00:00+00:00",
      "finishedDate": "2023-01-01T12:00:00+00:00",
      "result": "SUCCESS",
      "deploymentCommits":[
        {
          "repoUrl": "your-git-url",
          "refName": "your-branch-name",
          "startedDate": "2023-01-01T12:00:00+00:00",
          "finishedDate": "2023-01-01T12:00:00+00:00",
          "commitSha": "e.g. 015e3d3b480e417aede5a1293bd61de9b0fd051d",
          "commitMsg": "optional-commit-message"
        }
      ]
    }'

Our deployment tool is Octopus Deploy. Ideally it will be supported by DevLake in the future, but until then, webhooks is the only way to go.

[mieliespoor]

Adding a project name attribute to the body, would make it easily backward compatible, as if it is empty, current behaviour will continue.

[klesh]

Ah, I see.

The key point is: “We have a 1-1 relationship between the repository and the deployment project”.
That means you can use the deployment project name as a variable instead of hardcoding constants for each project.

Here’s an idea:

1. Define a new route in the webhook plugin, e.g. /projects/:projectName/deployments.
2. Implement a new ApiResourceHandler (based on the existing PostDeploymentCicdTask) that will:
   • Create the missing webhook connection for the given project
   • Then call PostDeploymentCicdTask to finish the rest of the workflow.

This way, we minimize effort while keeping compatibility.

PS: Am I correct in assuming that putting the projectName in the request URL is just as straightforward as putting it in the body?

[mieliespoor]

Yes, that looks like a neat approach.