--- title: About the forgeops repository description: Use ForgeRock's forgeops repository to customize and deploy the Ping Identity Platform on a Kubernetes cluster. component: forgeops version: 7.4 page_id: forgeops::forgeops canonical_url: https://docs.pingidentity.com/forgeops/7.4/forgeops.html keywords: ["forgeops Repository"] section_ids: forgeops-updates: Repository updates forgeops-reference: Repository reference directories: Directories bin: bin charts: charts cluster: cluster config: config docker: docker etc: etc jenkins_scripts: jenkins-scripts kustomize: kustomize legacy_docs: legacy-docs files_in_the_top_level_directory: Files in the top-level directory gcloudignore_gitchangelog_rc_gitignore: .gcloudignore, .gitchangelog.rc, .gitignore license: LICENSE makefile: Makefile notifications_json: notifications.json readme_md: README.md forgeops-fork: Git clone or Git fork? --- # About the `forgeops` repository Use ForgeRock's [`forgeops` repository](https://github.com/ForgeRock/forgeops.git) to customize and deploy the Ping Identity Platform on a Kubernetes cluster. The repository contains files needed for customizing and deploying the Ping Identity Platform on a Kubernetes cluster: * Files used to build Docker images for the Ping Identity Platform: * Dockerfiles * Scripts and configuration files incorporated into ForgeRock's Docker images * Canonical configuration profiles for the platform * Kustomize bases and overlays In addition, the repository contains numerous utility scripts and sample files. The scripts and samples are useful for: * Deploying ForgeRock's CDK and CDM quickly and easily * Exploring monitoring, alerts, and security customization * Modeling a CI/CD solution for cloud deployment Refer to [Repository reference](#forgeops-reference) for information about the files in the repository, recommendations about how to work with them, and the support status for the files. ## Repository updates New `forgeops` repository features become available in the `release/7.4-20240805` branch of the repository from time to time. When you start working with the `forgeops` repository, clone the repository. Depending on your organization's setup, you'll clone the repository either from ForgeRock's public repository on GitHub, or from a fork. See [Git clone or Git fork?](#forgeops-fork) for more information. Then, check out the `release/7.4-20240805` branch and create a working branch. For example: ``` $ git checkout release/7.4-20240805 $ git checkout -b my-working-branch ``` ForgeRock recommends that you regularly incorporate updates to the `release/7.4-20240805` into your working branch: 1. [Get emails or subscribe to the ForgeOps RSS feed](rn/rn.html) to be notified when there have been updates to ForgeOps 7.4. 2. Pull new commits in the `release/7.4-20240805` branch into your clone's `release/7.4-20240805` branch. 3. Rebase the commits from the new branch into your working branch in your `forgeops` repository clone. It's important to understand the impact of rebasing changes from the `forgeops` repository into your branches. [Repository reference](#forgeops-reference) provides advice about which files in the `forgeops` repository to change, which files not to change, and what to look out for when you rebase. Follow the advice in [Repository reference](#forgeops-reference) to reduce merge conflicts, and to better understand how to resolve them when you rebase your working branch with updates that ForgeRock has made to the `release/7.4-20240805` branch. ## Repository reference For more information about support for the `forgeops` repository, see [Support from ForgeRock](start/support.html). ### Directories #### bin Example scripts you can use or model for a variety of deployment tasks. Recommendation: Don't modify the files in this directory. If you want to add your own scripts to the `forgeops` repository, create a subdirectory under bin, and store your scripts there. Support Status: Sample files. [Not supported by ForgeRock.](start/support.html#commercial-support) #### charts Helm charts. Recommendation: Don't modify the files in this directory. If you want to update a values.yaml file, copy the file to a new file, and make changes there. Support Status: Technology preview. [Not supported by ForgeRock.](start/support.html#commercial-support) #### cluster Example script that automates Minikube cluster creation. Recommendation: Don't modify the files in this directory. Support Status: Sample file. [Not supported by ForgeRock.](start/support.html#commercial-support) #### config Deprecated. Supported an older implementation of the CDK. #### docker Contains three types of files needed to build Docker images for the Ping Identity Platform: Dockerfiles, support files that go into Docker images, and configuration profiles. **Dockerfiles** Common deployment customizations require modifications to Dockerfiles in the docker directory. Recommendation: Expect to encounter merge conflicts when you rebase changes from ForgeRock into your branches. Be sure to track changes you've made to Dockerfiles, so that you're prepared to resolve merge conflicts after a rebase. Support Status: Dockerfiles. [Support is available from ForgeRock.](start/support.html#commercial-support) **Support Files Referenced by Dockerfiles** When customizing ForgeRock's default deployments, you might need to add files to the docker directory. For example, to customize the AM WAR file, you might need to add plugin JAR files, user interface customization files, or image files. Recommendation: If you only add new files to the docker directory, you should not encounter merge conflicts when you rebase changes from ForgeRock into your branches. However, if you need to modify any files from ForgeRock, you might encounter merge conflicts. Be sure to track changes you've made to any files in the docker directory, so that you're prepared to resolve merge conflicts after a rebase. Support Status: Scripts and other files from ForgeRock that are incorporated into Docker images for the Ping Identity Platform: [Support is available from ForgeRock.](start/support.html#commercial-support) User customizations that are incorporated into custom Docker images for the Ping Identity Platform: [Support is not available from ForgeRock.](start/support.html#commercial-support) **Configuration Profiles** Add your own configuration profiles to the docker directory using the export command. Do not modify ForgeRock's internal-use only `idm-only` and `ig-only` configuration profiles. Recommendation: You should not encounter merge conflicts when you rebase changes from ForgeRock into your branches. Support Status: Configuration profiles. [Support is available from ForgeRock.](start/support.html#commercial-support) #### etc Files used to support several examples, including the CDM. Recommendation: Don't modify the files in this directory (or its subdirectories). If you want to use CDM automated cluster creation as a model or starting point for your own automated cluster creation, then create your own subdirectories under etc, and copy the files you want to model into the subdirectories. Support Status: Sample files. [Not supported by ForgeRock.](start/support.html#commercial-support) #### jenkins-scripts For ForgeRock internal use only. Do not modify or use. #### kustomize Artifacts for orchestrating the default deployment of Ping Identity Platform using Kustomize. | | | | - | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The forgeops install command does not use the `kustomization.yaml` file during deployment. Therefore, any configuration changes you incorporate in the `kustomization.yaml` file will not be used by the forgeops install command. | Support Status: Kustomize bases and overlays. [Support is available from ForgeRock.](start/support.html#commercial-support) #### legacy-docs Documentation for deploying the Ping Identity Platform using DevOps techniques. Includes documentation for supported and deprecated versions of the `forgeops` repository. Recommendation: Don't modify the files in this directory. Support Status: Documentation for supported versions of the `forgeops` repository: [Support is available from ForgeRock.](start/support.html#commercial-support) Documentation for deprecated versions of the `forgeops` repository: [Not supported by ForgeRock.](start/support.html#commercial-support) ### Files in the top-level directory #### .gcloudignore, .gitchangelog.rc, .gitignore For ForgeRock internal use only. Do not modify. #### LICENSE Software license for artifacts in the `forgeops` repository. Do not modify. #### Makefile For ForgeRock internal use only. Do not modify. #### notifications.json For ForgeRock internal use only. Do not modify. #### README.md The top-level `forgeops` repository README file. Do not modify. ## Git clone or Git fork? For the simplest use cases—a single user in an organization installing the CDK or CDM for a proof of concept, or exploration of the platform—cloning ForgeRock's public `forgeops` repository from GitHub provides a quick and adequate way to access the repository. If, however, your use case is more complex, you might want to fork the `forgeops` repository, and use the fork as your common upstream repository. For example: * Multiple users in your organization need to access a common version of the repository and share changes made by other users. * Your organization plans to incorporate `forgeops` repository changes from ForgeRock. * Your organization wants to use pull requests when making repository updates. If you've forked the `forgeops` repository: * You'll need to synchronize your fork with ForgeRock's public repository on GitHub when ForgeRock releases a new release tag. * Your users will need to clone your fork before they start working instead of cloning the public `forgeops` repository on GitHub. Because procedures in the [CDK documentation](cdk/overview.html) and the [CDM documentation](cdm/overview.html) tell users to clone the public repository, you'll need to make sure your users follow different procedures to clone the forks instead. * The steps for initially obtaining and updating your repository clone will differ from the steps provided in the documentation. You'll need to let users know how to work with the fork as the upstream instead of following the steps in the documentation.