With the Git Integration enabled in the environment, you can use the Git menu from Classic Manager or APIM Git APIs to perform Git operations on APIM 3.0 assets. APIM 3.0 currently supports GitHub as a provider. If the Git Integration isn't set up in your environment, the following topics will help you get started:

• Git Integration overview
• How to configure GitHub and the SnapLogic environment
• How to track projects and assets

In Classic manager, you can view project spaces and projects that contain APIM 3.0 Services, Service versions, Policies, pipelines, files, and tasks they contain. In a project, a Service folder contains version folders and version folders contain endpoint folders. Each folder contains a .json metadata folder, api-service-metadata.json, api-service-version-metadata.json, and api-service-version-endpoint.metada.json, respectively.

This page describes the following:

• Supported operations
• Using gitignore
• Limitations and known issues

Supported operations

Currently, APIM 3.0 supports the following SnapLogic Git operations:

• Check Git Repository
• Add to Repository: Stages all changes in a Service for the next commit. If a Service has multiple versions, they are all staged. If you create a new Service version after the initial add, you must add the Service again to track the new version.
• Remove from Repository
• Commit to Git
• Git Pull
• Untrack from Git
• Discard Changes: The equivalent of git restore, discards local changes and returns asset state to that of the Git repository.

Using gitignore

You can prevent the Git Integration from adding specific Service versions to source control by adding a .gitignore file to the parent project space or project. Add the Service version path(s) to ignore in the file. Git will not track any assets in the specified projects.

For example, assuming a parent project space of 01-MyProjects, the following line in a .gitignore file prevents Version 1.0 of the Hello-World Service from being tracked.

/Hello-World/1.0

Limitations and known issues

The Git Integration has the following limitations:

• You can't track applications or subscriptions.
• When using Checkout Git Repository or Git Pull to move or update assets in a different environment, the native endpoints and policies associated with a Service version fail to propagate to the new environment if:
  • The target environment doesn't have the same relative path to those assets.
  • The user performing the operation doesn't have permission for those assets in the target environment.

  In either case, native endpoints become external endpoints with the upstream URL set to "https://temporary.endpoint".

• When using Checkout Git Repository or Git Pull to move or update a Service version in a different environment, if a Snaplex with the same name and relative path must be available in the new environment, or you need to explicitly re-select a Server (Snaplex) in the new environment.
• The checkout of a Service fails if the Service slug is already in use in the environment.

Troubleshooting

If an expected Service doesn't populate from a git pull or checkout, a Service with the same URL slug might already exist. To resolve a conflict:

• Edit the existing Service to change its URL Slug.
• Edit the Service slug for the Service you are trying to pull. Change the Service slug in the api_service_metadata.json file.