GitLab has made it easier for you to build project management automation with a project webhook. This webhook is triggered when a project is created or deleted. Automation can now be built without relying on continuous API calls, which is cumbersome and puts unnecessary performance load on your GitLab instance.
Problem to solve
Customers want to know when projects are created so they can trigger automated processes.
For example:
Ensure that the project has settings that adhere to their organization's standards.
Capture the project creation in their external systems.
Automatically add users to project that follow an inner sourcing model.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Note that we're interested in this because of documentation on GitLabForm: Automate configuring new GitLab projects with GitLabForm. Their recommendation only works for self-managed GitLab through the project_create, project_rename, and project_transferSystem hooks because this feature is missing. Not sure if this needs to be expanded to fully cover that use case, especially the project rename and transfer events.
@lohrc As I shared in a related issue, I think that ideally each product group should be responsible for surfacing webhooks for there features where relevant. I realize we should provide some guidance around this and I think our team could assist.
We have an open issue to define documentation here, but we can also provide support as needed. I think by exposing webhooks (and APIs) for our features, we give customers lots of flexibility to build automations, pull data into business systems, or integrate with tools to accomplish specific tasks we may never address through the UI.
@m_frankiewicz would it make sense to leverage this Webhook feature as a means to work with the Technical Writing team to walk through the development process of a webhook? I feel like it's a relatively simple one to build out and could help, like what Grant mentioned, future writing the docs for development of webhooks across the platform.
@poffey21 I just bumped into this feature issue when looking at popular webhooks issues. We have a Community contribution from @stingrayza that is adding a group webhook when a project is created !160887 (merged), working from #454581 (closed). @stingrayza I wonder if we should reference this issue instead of #454581 (closed) as the issue for your feature? Since #454581 (closed) specifically is saying "repo creation" which the customer may be intending to mean project creation, but repo creation could technically be a separate hook as projects can be created without a repo initialized. Project create/delete hooks (rather than repo-specifically) would be the more important feature, so I think your implementation is spot on.
{"event_name":"project_create","created_at":"2024-11-13T15:33:19Z","updated_at":"2024-11-13T15:33:19Z","name":"fire me a webhook","path":"fire-me-a-webhook","path_with_namespace":"gl-demo-ultimate-rhook/project-webhook-test/fire-me-a-webhook","project_id":64494335,"project_namespace_id":97426831,"owners":[{"name":"Raimund Hook","email":"[REDACTED]"}],"project_visibility":"public"}