An endpoint is an instance of a DevOps application that connects to Automation Pipelines and provides data for your pipelines to run, such as a data source, repository, or notification system.
Endpoints can be cloud-based or on-premises.
Your role in Automation Pipelines determines how you use endpoints.
- Administrators and developers can create, update, delete, and view endpoints.
- Administrators can mark an endpoint as restricted, and run pipelines that use restricted endpoints.
- Users who have the viewer role can see endpoints, but cannot create, update, or delete them.
For more information, see How do I manage user access and approvals in Automation Pipelines.
To connect Automation Pipelines to an endpoint, follow these steps.
- Add a task in your pipeline
- Configure the task so that it communicates with the endpoint.
- Verify that Automation Pipelines can connect to the endpoint by clicking Validate.
- Then, when you run the pipeline, the task connects to the endpoint so that it can run the task.
For information about the task types that use these endpoints, see What types of tasks are available in Automation Pipelines.
|What it provides
|Connects on-premises SSH, PowerShell, or REST task hosts.
|Before you create an agent endpoint, you must create a cloud proxy.
|Creates build plans.
|Native builds can use Docker hosts for deployment.
When a pipeline includes an image from Docker Hub, you must ensure that the image has cURL or wget embedded before you run the pipeline. When the pipeline runs, Automation Pipelines downloads a binary file that uses cURL or wget to run commands.
|Registers container images so that a Docker build host can pull images.
|Connects to a Gerrit server for reviews and trigger
|Triggers pipelines when developers update code and check it in to the repository.
Git Hub Enterprise 2.1.8
Git Lab Enterprise 11.9.12-ee
|Builds code artifacts.
|1.6.* and 2.*
|Creates a Jira ticket when a pipeline task fails.
|Automates the steps that deploy, scale, and manage containerized applications.
All versions supported
When using a Kubernetes API endpoint in the pipeline workspace, Automation Pipelines creates the necessary Kubernetes resources such as ConfigMap, Secret, and Pod to run the continuous integration (CI) task or custom task. Automation Pipelines communicates with the container by using the NodePort.
For more information about configuring the workspace, see Configuring the Pipeline Workspace.
|Create tasks that run PowerShell scripts on Windows or Linux machines.
|4 and 5
|Create tasks that run SSH scripts on Windows or Linux machines.
|TFS, Team Foundation Server
|Manages source code, automated builds, testing, and related activities.
|2015 and 2017
|VMware Aria Automation Orchestrator
|Arranges and automates the workflows in your build process.
|7.* and 8.*
An example of a cloud-based endpoint is a local GitHub repository. In a pipeline task that uses a cloud-based repository, you set the cloud proxy to Default. For example:
Automation Pipelines connects to endpoints on premises through a cloud proxy. Your network configuration and the location of your endpoints on premises in those networks determine how many cloud proxy instances you need. If all your endpoints on premises are in the same network, install a single cloud proxy. If your endpoints on premises reside in different networks, install one cloud proxy for each independent network. Then, in the endpoint configuration in Automation Pipelines, select the cloud proxy that resides in the same network as your endpoint.
The cloud proxy routes messages between your on-premises endpoints and Automation Pipelines, and enables the collection of data from those endpoints. On-premises endpoints are not reachable over the public Internet because they reside behind a firewall.
To set up a cloud proxy for your on-premises endpoint, in Automation Assembler, you download the cloud proxy OVA and install it in your vCenter instance.
An example on-premises endpoint, which requires a cloud proxy, resembles:
For an example of setting up the cloud proxy, see Setting up Automation Pipelines to model my release process.
Example YAML code for a GitHub endpoint
This example YAML code defines a GitHub endpoint that you can refer to in a Git task.
--- name: github-k8s tags: [ ] kind: ENDPOINT properties: serverType: GitHub repoURL: https://github.com/autouser/testrepok8s branch: master userName: autouser password: encryptedpassword privateToken: '' description: '' type: scm:git isLocked: false ---