Rely.io
  • 📌What is Rely.io?
  • 💡How Rely.io works
  • 📑Getting Started Guide
    • Create an account for your organization
    • Add your first plugin
    • Import services into the Service Catalog
    • Make the Software Catalog your own
    • What's Next?
  • 🌈Basic Concepts
    • Entities
    • Blueprints
    • Property Data Types
    • Catalogs
    • Data Model
    • Plugins
    • User Blueprints vs Plugin Blueprints
    • Actions and Automations
      • Automation Rules
      • Self-Service Actions
    • Home Pages
    • Scorecards
  • 📚Guides & Tutorials
    • Enhancing Deployment Visibility through Gitlab Pipelines and Rely's API
  • 🖥️Software Catalog
    • Overview and Use Cases
    • Usage Guide
      • Creating a new Entity
      • Updating an Entity
      • Tracking Entity Changes
      • Customizing an Entity's Page
      • Customizing a Catalog
      • Creating a new Blueprint & Catalog
      • Updating a Blueprint
      • Tracking Blueprint Changes
    • Relevant Guides
    • Troubleshooting
  • 🥇Scorecards
    • Overview and Use Cases
    • Usage Guide
      • Creating a Scorecard
      • Updating a Scorecard
      • Evaluating Performance
    • Scorecard Examples
      • Production Readiness Scorecard Example
      • DORA Metrics Scorecard Example
      • Operational Maturity Example
  • 🎨Home Pages
    • Overview and Use Cases
    • Usage Guide
      • Creating a New Tab
  • ⚡Self-Service Actions
    • Overview and Use Cases
    • Usage Guide
      • Configuring your Self Service Agent
      • Managing your Actions Catalog
      • Self-Service Actions as Code
      • Running Actions
      • Tracking Action Runs
  • ↗️Plugins & Automation
    • What happens when you install a Plugin?
    • Self-Hosting Plugins using Galaxy
    • 🤖Automation Rules
      • Overview and Use Cases
      • Usage Guide
        • Creating an Automation Rule
        • Updating an Automation Rule
        • Tracking Automation Changes
        • Managing Automation Suggestion
    • 🔌Plugin Installation Guides
      • ⭐AWS
      • Bitbucket
      • ⭐Flux
      • GitHub
      • GitLab
      • ⭐Google Cloud Platform (GCP)
      • ⭐Kubernetes
      • ⭐OpsGenie
      • ⭐PagerDuty
      • ⭐Snyk
      • ⭐SonarQube
  • 🌐Public API
    • Audit Logs
    • Automations & Self-Service Actions
    • Automation Suggestions
    • Blueprints
    • Dashboards & Views
    • Entities
    • Scorecards
    • Self-Service Action Runs
    • Time Series
    • Users
    • Webhooks
  • ⚙️Invite Users
  • 🛡️Security & Compliance
    • Single Sign-On (SSO)
      • SAML with Google Workspace
      • SAML with Microsoft Entra ID
      • SAML with Okta
      • OIDC with Okta
      • OIDC with Google Workspace
  • 🏥Troubleshooting
  • ❓FAQ
Powered by GitBook
On this page
  • Self-Service Action Descriptor
  • Triggers
  • Actions
  • Data Manipulation
  • Example 1 (Creating a Gitlab Repository)
  • Learn More

Was this helpful?

  1. Basic Concepts
  2. Actions and Automations

Self-Service Actions

Self-Service Action Descriptor

Regardless of whether you're using UI editing or GitOps to manage your self-service actions, the definitions are backed by JSON files. Each file is a fully compliant OpenAPI 3 spec file, with our own specific extensions.

You can still use Self Service Actions even if you don't use OpenAPI/Swagger.

We use the OpenAPI spec as a base for automation rule configuration, since it's an open spec with official support for extensions. That lets us extend it to be an automation rule descriptor spec with optional usage of actual OpenAPI fields.

All automation rule descriptors have 5 metadata fields:

  • ID: A unique identifier for the rule.

  • Name: A user-friendly display name.

  • Description (Optional): A concise overview of the action for further context.

  • Is Active: Boolean parameter that determines whether the self-service-action is active and should be executed or not.

  • Type: Defines the type of rule (selfServiceAction) .

Triggers

Triggers are conditions that initiate the execution. For self-service actions, the only available trigger type is manual meaning users need to manual execute the action either via the UI or API.

The trigger sections also specify the arguments (and their data-types) that a self-service action requires to be triggered, which are used as input when triggering an action from the UI.

E.g.

"triggers": [
   {
      "type":"manual",
      "inputSchema":{
         "type":"object",
         "title":"Repository Details",
         "required":[
            "repositoryName",
            "visibility"
         ],
         "properties":{
            "repositoryName":{
               "type":"string",
               "title":"Repository Name",
               "description": "The name of the Repository in Gitlab"
            },
            "visibility":{
               "type":"string",
               "title":"Visibility",
               "description": "The visibility of the Repository ('hidden', 'internal', 'public')",
               "enum": ["private", "internal", "public"],
               "default":"hidden"
            }
         }
      }
   }
]

Actions

Data Manipulation

Example 1 (Creating a Gitlab Repository)

{
	"id": "gitlab-repo-creation",
	"title": "Create Repository in GitLab",
	"description": "Create a new GitLab repository",
	"isActive": true,
	"order": 0,
	"type": "selfServiceAction",
	"arguments": {},
	"triggers": [
   {
      "type":"manual",
      "inputSchema":{
         "type":"object",
         "title":"Repository Details",
         "required":[
            "repositoryName",
            "visibility"
         ],
         "properties":{
            "repositoryName":{
               "type":"string",
               "title":"Repository Name",
               "description": "The name of the Repository in Gitlab"
            },
            "visibility":{
               "type":"string",
               "title":"Visibility",
               "description": "The visibility of the Repository ('hidden', 'internal', 'public')",
               "enum": ["private", "internal", "public"],
               "default":"hidden"
            }
         }
      }
	}],
	"actions": [{
	   "type": "httpRequest",
	   "args": {
		   "body": "{\"name\": \"{{ data.repositoryName }}\", \"visibility\": \"{{ data.visibility }}\"}",
		   "path": "",
		   "method": "post",
		   "baseUrl": "https://gitlab.com/api/v4/projects",
		   "headers": {
			   "Content-Type": "application/json",
			   "PRIVATE-TOKEN": "{{ env('GITLAB_TOKEN_ID') }}"
		   }
	   }
        }],
	"tags": [{
      "key": "data-source",
      "value": "gitlab"
    }]
}

Learn More

PreviousAutomation RulesNextHome Pages

Last updated 9 months ago

Was this helpful?

Actions are the operations executed by the automation rule when a trigger condition is met. Actions in self-service action rules resemble the schema and syntax of .

Data Manipulation in self-service action rules resemble the behaviour of actions in .

Self Service Actions
Self Service Actions
Self Service Actions
🌈

Configuring your Self Service Agent

Running Actions

Tracking Action Runs

actions in automation rules
automation rules