Add all properties that should be exposed to API::Helpers::IntegrationsHelpers.integrations.Add the integration’s class ( ::Integrations::FooBar) to API::Helpers::IntegrationsHelpers.integration_classes.To expose the integration in the REST API: Module Integrations class FooBar < Integration def test ( data ) success = test_api_key ( data ) ] end end end Expose the integration in the REST API This example defines an integration that responds to commit and merge_request events: Wiki page event ✓ wiki_page A wiki page is created or updated. Vulnerability event vulnerability A new, unique vulnerability is recorded. Tag push event ✓ tag_push New tags are pushed to the repository. Push event ✓ push A push is made to the repository. Pipeline event pipeline A pipeline status changes. Confidential comment event confidential_note A new comment on a confidential issue is added. Comment event comment A new comment is added. Job event job Merge request event ✓ merge_request A merge request is created, updated, or merged. Confidential issue event ✓ confidential_issue A confidential issue is created, updated, or closed. Issue event ✓ issue An issue is created, updated, or closed. Deployment event deployment A deployment starts or finishes. Commit event ✓ commit A commit is created or updated. The following events are supported for integrations: Event type Default Value Trigger Alert event alert A a new, unique alert is recorded. The class method Integration.supported_events in your model. You can specify the events you’re interested in by overriding The supported events have some overlap with webhook events,Īnd receive the same payload. Which gets passed a payload hash with details about the event. Integrations are triggered by calling their #execute method in response to events in GitLab, At the moment we don’t recommend using this for new integrations. With data fields the values are stored in a separate table per integration. There is an alternative approach using Integration.data_field, which you may see in other integrations. You should also define validations for all your properties.Īlso refer to the section Customize the frontend form below to see how these propertiesĪre exposed in the frontend form for the integration. You must not write to the properties hash, you must use the generated setter method instead. You should always access the properties through their getters, and not interact with the properties hash directly. Fields stored in Integration#properties should be accessed by these accessors directly on the model, just like other ActiveRecord attributes. Here we would have #url, #url= and #url_changed?, to manage the url field. Integration.prop_accessor installs accessor methods on the class. Module Integrations class FooBar < Integration prop_accessor :url prop_accessor :tags end end Īdd the integration as an association on Project:.Add the integration’s underscored name ( 'foo_bar') to Integration::INTEGRATION_NAMES.Which can be viewed in the integration settings. In GitLab through an associated ServiceHook model, and automatically records request logs For integrations that primarily trigger HTTP calls to external services, you canĪlso use the Integrations::HasWebHook concern.For certain types of integrations, you can also build on these base classes:.For example, Integrations::FooBar in app/models/integrations/foo_bar.rb.Add a new model in app/models/integrations extending from Integration.Add a new integration Define the integration
You’re welcome to ping you need clarification or spot any outdated information. Which are part of our main Rails project.Īlso see our direction page for an overview of our strategy around integrations. This page provides development guidelines for implementing GitLab integrations, Integration examples Integrations development guidelines.
0 kommentar(er)
