Creating Resources

JFrog Pipelines Documentation

Products

JFrog Pipelines

Content Type

User Guide

ft:sourceType

Paligo

All resources are defined in a pipeline YAML under the resources tag, as shown below. After a resource is defined and committed to a source control, it is consumed within a pipeline, based on the scope defined for the pipeline source.

Sharing resources across environments

When defining resources, the recommended approach is to define them in a pipeline source that is shared across environments in the same Project. This ensures that the resources are available across environments in a project. For more information, see Creating a Project - Pipelines Resources.Create a Project

While each resource has its own specific configuration, they all require a name and a type.

YAML Schema

resources:
  - name:               <string>
    type:               <resource type name>
    configuration:
      <as required by type>

Tag	Description of usage	Required/Optional
`name`	An alphanumeric string (underscores are permitted) that makes it easy to infer what the resource represents. This name is used to refer to the resource in steps, and must be unique across all repositories in your JFrog Pipelines Project. Example: `aws_creds` to represent AWS keys. Note After the pipeline performs a sync, it is recommended to not change the name of the resource. If you change the name of the resource, it is treated as a new resource and all its version history is lost. In addition, the name of the resource will need to be updated in all the places it appears in the pipeline. Within the scope of a pipeline (across a Project or environment), no two resources can share the same name.	Required
`type`	Name of the resource type that this resource is an instance of. Note After the pipeline performs a sync, its type cannot be modified.	Required
`configuration`	Specifies configuration settings, which vary for each `type` of resource. Commonly included in this block is a setting that assigns an integrationthrough which the resource will be authenticated and accessed. The integration must be compatible with the `type`of the resource. The name of the integration field will vary by the resource.	Required

Tag

Description of usage

Required/Optional

name

An alphanumeric string (underscores are permitted) that makes it easy to infer what the resource represents. This name is used to refer to the resource in steps, and must be unique across all repositories in your JFrog Pipelines Project.

Example: aws_creds to represent AWS keys.

Note

After the pipeline performs a sync, it is recommended to not change the name of the resource. If you change the name of the resource, it is treated as a new resource and all its version history is lost. In addition, the name of the resource will need to be updated in all the places it appears in the pipeline.
Within the scope of a pipeline (across a Project or environment), no two resources can share the same name.

Required

type

Name of the resource type that this resource is an instance of.

Note

After the pipeline performs a sync, its type cannot be modified.

Required

configuration

Specifies configuration settings, which vary for each type of resource.

Commonly included in this block is a setting that assigns an integrationthrough which the resource will be authenticated and accessed. The integration must be compatible with the typeof the resource. The name of the integration field will vary by the resource.

Required

Examples - Resource Definition

These examples show the YAML definition for GitRepo and Image resources:

Example 1 - GitRepo Resource

resources:
  - name: gitrepo_trigger
    type: GitRepo
    configuration:
      gitProvider: my_github
      path: myuser/repo-name
      branches:
        include: master

Example 2 - Image Resource

resources: 
  - name: Image_1
    type: Image
    configuration:    
      registry: PSSG_DockerRegistry      
      imageName: docker/jfreq_win        
      imageTag: latest 
      autoPull: true

Modifying Pipeline Resources

In Pipelines, resources and their versions are tightly coupled. Therefore, when a resource is deleted, its historical data is permanently affected. This can mess up your DevOps Assembly Lines as it is a connected inter-dependent workflow.

The following rules apply when editing resources:

If you modify a resource's name, it is treated as new resource.
A resource's type cannot be modified.

If your pipeline is failing because of a modified resource tag,the only option to recover your pipeline is to delete the resource definition. Deletion of a resource is a two-step process: