More workbench improvements

assets/design-system/src/utils/urls.ts

@@ -59,15 +59,19 @@ export function isValidRepoUrl(url: string): boolean {
   return false
 }
 
-export function prettifyRepoUrl(repoUrl: string) {
-  const [owner, name] = repoUrl
+export function prettifyRepoUrl(
+  repoUrl: string,
+  showFullPath: boolean = false
+) {
+  const fullPath = repoUrl
     .trim()
     .replace(/^git@[^:]+:/, '')
     .replace(/^ssh:\/\/[^/]+\/?/, '')
     .replace(/^https?:\/\/[^/]+\/?/, '')
     .replace(/^\/+/, '')
     .replace(/\.git$/, '')
-    .split('/')
 
-  return owner && name ? `${owner}/${name}` : repoUrl
+  const [owner, name] = fullPath.split('/')
+
+  return showFullPath ? fullPath : owner && name ? `${owner}/${name}` : repoUrl
 }

assets/public/setup-guides/webhooks/asana.md

@@ -0,0 +1,54 @@
+# Asana Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in Asana against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts, new tickets, and workflow updates.
+
+## 1. Create the webhook in Plural
+
+In Plural, go to the webhook creation flow and choose:
+
+- Type: Ticketing
+- Provider: ASANA
+
+Fill in:
+
+- Name: a clear name like Asana Production Tickets
+- URL: the callback URL Plural gives you
+- Secret: a strong shared secret
+
+Save the webhook in Plural.
+
+## 2. Register URL and secret in Asana
+
+In Asana, open your app or integration settings and create a webhook subscription:
+
+- Target URL: paste the Plural webhook URL
+- Secret/token field: paste the same secret from Plural
+
+If Asana requires signing secrets per endpoint, ensure the secret is bound to this exact URL.
+
+## 3. Configure triggers to send events to Plural
+
+Enable triggers that map to operational ticketing activity:
+
+- New task/ticket created
+- Task moved to incident/alerts project
+- Critical priority changes
+- Status transitions for incident-related work
+
+Prefer project-level or workspace-level filters so only relevant events are sent.
+
+## 4. Validate delivery
+
+Trigger a test event in Asana (for example create a test ticket) and verify in Plural:
+
+- request is received
+- signature/secret validation succeeds
+- event appears in webhook activity
+
+## 5. Troubleshooting
+
+If events fail:
+
+- confirm URL exactly matches the Plural endpoint
+- rotate and re-enter the secret on both sides
+- ensure the selected project/workspace scope includes the event source

assets/public/setup-guides/webhooks/datadog.md

@@ -0,0 +1,42 @@
+# Datadog Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in Datadog against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts and monitor state changes.
+
+## 1. Create the webhook in Plural
+
+In Plural configure:
+
+- Type: Observability
+- Provider: DATADOG
+- Name: for example Datadog Production Alerts
+- Secret: shared secret used for verification
+
+Plural stores the secret and gives you the target URL (if required by your flow).
+
+## 2. Register URL and secret in Datadog
+
+In Datadog integrations/webhooks:
+
+- Target URL: set to the Plural webhook URL
+- Secret/signing token: set to the same secret from Plural
+
+If custom headers are required, keep them aligned with your Plural validation policy.
+
+## 3. Configure alert triggers
+
+Enable triggers for relevant alert lifecycle events:
+
+- monitor alert triggered
+- monitor recovered
+- incident state changes
+- high-priority signal transitions
+
+Scope notifications to production monitors or incident-critical tags.
+
+## 4. Validate delivery
+
+Trigger a test monitor alert in Datadog and verify in Plural:
+
+- event received and authenticated
+- payload parsed
+- trigger evaluation sees alert state correctly

assets/public/setup-guides/webhooks/github.md

@@ -0,0 +1,47 @@
+# GitHub Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in GitHub against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts, new tickets, and issue lifecycle updates.
+
+## 1. Create the webhook in Plural
+
+Create a new webhook in Plural with:
+
+- Type: Ticketing
+- Provider: GITHUB
+- URL: Plural callback URL
+- Secret: shared secret used for signature verification
+
+## 2. Register URL and secret in GitHub
+
+In GitHub repository or organization settings:
+
+- go to Webhooks
+- click Add webhook
+- Payload URL: paste the Plural URL
+- Secret: paste the same secret configured in Plural
+- Content type: application/json
+
+## 3. Configure GitHub events
+
+Select events relevant to ticketing and alerts, for example:
+
+- Issues (opened, edited, closed, reopened)
+- Issue comments
+- Label changes
+- Projects if your team routes alert tickets through boards
+
+Use either individual events or Send me everything only in non-production environments.
+
+## 4. Test and verify
+
+Use GitHub's ping/test delivery and also create a test issue. In Plural, verify:
+
+- delivery succeeded (2xx)
+- event parsed successfully
+- issue/ticket event appears in webhook history
+
+## 5. Security recommendations
+
+- use a unique secret per webhook
+- rotate periodically
+- restrict admin rights for webhook management

assets/public/setup-guides/webhooks/gitlab.md

@@ -0,0 +1,46 @@
+# GitLab Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in GitLab against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts, new tickets, and incident issue updates.
+
+## 1. Create the webhook in Plural
+
+In Plural create:
+
+- Type: Ticketing
+- Provider: GITLAB
+- URL: incoming webhook URL from Plural
+- Secret: shared secret
+
+## 2. Register URL and secret in GitLab
+
+In GitLab project/group settings under Webhooks:
+
+- URL: paste the Plural URL
+- Secret token: paste the same secret from Plural
+- SSL verification: keep enabled unless your environment requires otherwise
+
+## 3. Configure GitLab triggers
+
+Enable events that correspond to ticket lifecycle:
+
+- Issues events
+- Notes/comments events (optional)
+- Labels changes (if used for severity)
+- Confidential issue updates where applicable
+
+For alert-driven workflows, scope to projects where alert tickets are created.
+
+## 4. Test the integration
+
+Use GitLab Test webhook for Issues events and then open a real test issue.
+
+Check Plural for:
+
+- successful request validation
+- processed event payload
+- activity logs with expected event type
+
+## 5. Operational tips
+
+- keep separate webhooks for staging and production projects
+- apply narrow event filters to reduce noise

assets/public/setup-guides/webhooks/grafana.md

@@ -0,0 +1,41 @@
+# Grafana Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in Grafana against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts and alert rule state transitions.
+
+## 1. Create the webhook in Plural
+
+Create a webhook in Plural with:
+
+- Type: Observability
+- Provider: GRAFANA
+- Secret: shared webhook secret
+
+Use the URL provided by Plural for incoming events.
+
+## 2. Register URL and secret in Grafana
+
+In Grafana Alerting contact points:
+
+- Contact point type: Webhook
+- URL: paste the Plural webhook URL
+- Secret/signature key: paste the Plural secret
+
+Set optional fields (headers, auth) only if your policy requires them.
+
+## 3. Configure Grafana triggers
+
+Bind the contact point to notification policies and routes for:
+
+- firing alerts
+- resolved alerts
+- selected folders/labels for incident-relevant rules
+
+Route only high-signal alerts to avoid noisy webhook traffic.
+
+## 4. Validate integration
+
+Use Grafana test notification and a real alert simulation. In Plural verify:
+
+- request accepted
+- signature check passed
+- firing and resolved events are visible

assets/public/setup-guides/webhooks/jira.md

@@ -0,0 +1,45 @@
+# Jira Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in Jira against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts, new tickets, and issue transitions.
+
+## 1. Create the webhook in Plural
+
+Configure a webhook in Plural with:
+
+- Type: Ticketing
+- Provider: JIRA
+- URL: Plural callback endpoint
+- Secret: shared signing secret
+
+## 2. Register URL and secret in Jira
+
+In Jira admin settings for webhooks:
+
+- Endpoint URL: paste Plural URL
+- Secret or authentication field: paste the Plural secret (if available in your Jira deployment)
+- Authentication: configure additional auth headers only if your policy requires it
+
+## 3. Configure Jira trigger events
+
+Enable events commonly used for alert workflows:
+
+- Issue created
+- Issue updated
+- Issue transitioned
+- Issue reopened/resolved
+
+If supported, apply JQL filter to include only incident/alert projects and severities.
+
+## 4. Validate end-to-end
+
+Create and transition a test issue in Jira. In Plural confirm:
+
+- webhook accepted
+- signature/secret check passed
+- trigger appears with expected metadata
+
+## 5. Best practices
+
+- keep dedicated Jira webhook per environment
+- document JQL filters with your on-call process
+- rotate secret after team ownership changes

assets/public/setup-guides/webhooks/linear.md

@@ -0,0 +1,45 @@
+# Linear Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in Linear against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts, new tickets, and issue status updates.
+
+## 1. Create the webhook in Plural
+
+In Plural, create webhook:
+
+- Type: Ticketing
+- Provider: LINEAR
+- URL: Plural endpoint URL
+- Secret: shared secret for request verification
+
+## 2. Register URL and secret in Linear
+
+In Linear workspace settings under API/Webhooks:
+
+- Webhook URL: paste Plural URL
+- Secret/signing key: paste same secret from Plural
+
+If Linear signs payloads, make sure Plural validates against this exact secret.
+
+## 3. Configure event subscriptions
+
+Enable the events that should drive Plural automation:
+
+- Issue created (new tickets)
+- Issue updated
+- Priority changed
+- State changed (triaged/in progress/done)
+
+Use team-based filters if only certain teams should send webhook data.
+
+## 4. Verify integration
+
+Create a test issue and transition its state. In Plural verify:
+
+- request accepted
+- event recorded
+- downstream automation or trigger evaluation runs correctly
+
+## 5. Maintenance
+
+- keep webhook ownership documented in your runbook
+- rotate secrets on schedule

assets/public/setup-guides/webhooks/newrelic.md

@@ -0,0 +1,42 @@
+# New Relic Webhook Setup for Plural
+
+Generate markdown documentation for creating a webhook in New Relic against plural. Plural allows a webhook to have a url and secret, you need to explain to the user how to register those, and how to configure the appropriate triggers so plural can receive events from alerts and incident lifecycle changes.
+
+## 1. Create the webhook in Plural
+
+Create webhook details in Plural:
+
+- Type: Observability
+- Provider: NEWRELIC
+- Secret: shared secret for verification
+
+Copy the Plural webhook URL.
+
+## 2. Register URL and secret in New Relic
+
+In New Relic workflows/destinations:
+
+- Destination type: webhook
+- URL: Plural webhook URL
+- Secret/signing credential: same secret as in Plural
+
+Ensure destination is enabled and reachable from New Relic.
+
+## 3. Configure trigger workflows
+
+Attach destination to workflows with conditions such as:
+
+- incident created/opened
+- incident acknowledged
+- incident closed
+- policy/condition severity changes
+
+Filter by account, policy, or tags to keep routing precise.
+
+## 4. Test and verify
+
+Send a test payload from New Relic and open a test incident. In Plural verify:
+
+- authenticated delivery
+- expected incident events captured
+- trigger automation reacts to open/close events