Chapter 2. Building an application with sample software templates RHTAP's ready-to-use software templates include default integrations with key technologies to secure and optimize your development experience: ACS (Advanced Cluster Security): Identifies and mitigates vulnerabilities early in the development process, strengthening your application from inception to deployment. Quay: Serves as a secure harbor for your container images, continuously scanning for vulnerabilities to keep your containerized applications safe. OpenShift Pipelines: Automates your build and deployment processes, providing a CI/CD framework that integrates seamlessly into your SDLC and accelerates your path to production. OpenShift GitOps: Maintains your infrastructure and application configurations in Git repositories, ensuring consistent and automated deployment across all environments. Additionally, RHTAP supports the development and containerization of applications in popular programming languages such as Java, Python, Node.js, and Go. Note After installing RHTAP, cluster administrators can customize the Red Hat Developer Hub portal with specific templates and enhancements. However, before customization, cluster administrators should familiarize themselves with the available software and pipeline templates through this guide. Understanding these templates is key to grasping how RHTAP supports a secure supply chain, laying the groundwork for any subsequent customization. 2.1. Setting the stage Ensure you have successfully installed RHTAP. If you integrated Jenkins during the installation of RHTAP, you must configure Jenkins with the appropriate credentials before using secure software templates. If you integrated Bitbucket during the installation of RHTAP, ensure the following prerequisites are met, as the secure software templates require them to create a source repository at the correct location: Create a project in a Bitbucket workspace . Create an app password in Bitbucket. Log in to Red Hat Developer Hub (RHDH) using the link provided by RHTAP installer at the end of the installation process. 2.2. Building an application On the RHDH portal, select Create , and then select a suitable template. For example, Quarkus Java - Trusted Application Pipeline. Building an application or microservice for your developers in RHDH using the templates offered by RHTAP involves three main steps: Provide application information Provide application repository information Provide deployment information Providing application information In the Name field, provide an application name. Your name may incorporate lowercase letters (a-z), numbers (0-9), and dashes (-), but it must start and end with a lowercase alphanumeric character. Examples of valid names are my-name or abc-123 , and the length should range from 1 to 63 characters. From the Owner dropdown list, select an appropriate RHDH component owner for this application. The default value is user:guest , which appears if no specific owner is registered in the system. If you have not registered an owner, retain the default user:guest selection. You can replace guest with your username to personalize ownership of the application. Select . The system displays the Application Repository Information form. Providing application repository information From the Host Type dropdown list, select a repository host type: GitHub GitLab Bitbucket In the Repository Name field, enter a repository name using A-Z, a-z, 0-9, underscore (_), and dashes (-). The system uses this name for the repository it creates on the host repository server. In the Repository Owner field, specify the username, organization name, or project within an organization that owns the Git repository. For example, in Bitbucket, you can find your username by navigating to Personal Bitbucket settings. In the Repository Server field, specify the repository server: If you select the Host type Description GitHub The field is pre-populated with github.com . However, you can enter your on-premises host URL without the HTTP protocol and without the .git extension. For example, github-github.apps.cluster-ljg9z.sandbox219.opentlc.com . GitLab The field is pre-populated with gitlab.com . However, you can enter your on-premises host URL without the HTTP protocol and without the .git extension. For example, gitlab-gitlab.apps.cluster-ljg9z.sandbox219.opentlc.com . Bitbucket The field is pre-populated with bitbucket.org . In the Repository Default Branch field, specify the default branch for your repository. The default is main , but you can specify a different branch name. For Bitbucket only: In the Workspace field, enter the name of your workspace that contains your project. In the Project field, enter the project key. The project key is located to the project name in Bitbucket. From the CI Provider dropdown list, select the continuous integration (CI) tool that the system uses to build, test, and deploy the application: For Host type Available CI providers Bitbucket Jenkins (SLSA 2) Tekton (SLSA 3) GitHub Jenkins (SLSA 2) Github Actions (SLSA 2) (Technology Preview) Tekton (SLSA 3) GitLab Jenkins (SLSA 2) GitLab CI (SLSA 2) Tekton (SLSA 3) Important If you use Bitbucket as your source repository with Tekton CI, you must add a webhook in Bitbucket . If you use GitLab as your source repository with Tekton CI, you must add a webhook in GitLab . If you use GitHub Actions , you must configure the required secrets in GitHub . If you use GitLab CI , you must configure the required secrets in GitLab . If you use Jenkins , you must add your application to Jenkins . Select . The system displays the Deployment Information form. Providing deployment information In the Image Registry field, specify the on-premises image registry URL without the HTTP protocol. Support registries include Quay (for example, quay.io ) and JFrog Artifactory (for example, tssc.jfrog.io ). In the Image Organization field, enter the image organization for the image registry you provided in the Step 1. In the Image Name field, enter an image name using only lowercase letters, digits, and separators. Separators include a period (.), up to two underscores (_), or one or more hyphens (-). For example, my-app_1.2 . Note You must ensure that the name does not start or end with a separator. In the Deployment Namespace field, enter the prefix for the namespaces or cluster where you intend to deploy your application. The system creates the namespaces as rhtap-app-development , rhtap-app-stage , and rhtap-app-prod . Note rhtap-app is the default deployment namespace prefix. Cluster administrators can customize this prefix. For instructions on how to customize the default deployment namespace prefix, refer to Customizing sample software templates . Select Review to review all the information that you added. Select Create . RHTAP initiates automated tasks to set up your application's infrastructure and deployment pipeline, including: Repository Creation and Configuration: Creates a new repository in your specified hosting service, including the GitOps repository and the source repository. Argo CD Integration: Creates and configures Argo CD resources to orchestrate the deployment of your application across specified namespaces. Namespace Creation: Generates namespaces for development, staging, and production environments. Pipeline Definition: Adds a pipeline definition, providing a "Pipelines as Code" model for building, testing, and deploying your application. 2.3. Reviewing application After creating an application using RHTAP, you can review its components, source code, GitOps configurations, and associated documentation. Quick analysis For a quick review, click the links displayed on the "Run of ... " page. These links provide access to important resources such as: Source repositories GitOps repositories Comprehensive analysis For a detailed analysis, follow these steps: Select Open Component in catalog or navigate to the Catalog , where your newly created application is listed. Examining source code: Go to the Overview tab and select View Source to open the repository containing your application's source code. Reviewing deployment history: In the Overview tab, navigate to the Deployment summary section to review the application's deployment across namespaces. Select any Argo CD app to view deployment details in Argo CD, or click a commit ID from the Revision column to review changes in GitLab or GitHub. Reviewing GitOps repository: On the Overview tab, use the Kind dropdown to select Resource and find the relevant GitOps repository. Select View Source to examine the GitOps configurations directly. Alternatively, for a broader overview including technical documentation, select View TechDocs from the Catalog section and then choose the GitOps repository under Home > Repository . Reviewing documentation: From the Overview tab, select View Tech Docs . This opens the technical documentation for your application, providing detailed insights into its features, configuration steps, and usage. 2.4. (Optional) Unregistering application This process removes the application's source and GitOps repository from your catalog and resource view, essentially hiding it. The application remains functional within the cluster. Since the underlying source and GitOps repositories are not removed, you can re-register unregistered applications at any time. Navigate to the Catalog and select the component that you want to unregister. Select vertical three-dot menu associated with the component, and then select Unregister entity . The system displays a confirmation dialog box. Select Unregister Location . This removes the application's Git repository from your catalog view. Navigate to the Catalog , from the Kind drop down list, select Resource , and then unregister the corresponding GitOps resource. Remove the application from the cluster, by running the following command: oc delete application your-app-name-app-of-apps -n rhtap 1 1 Replace rhtap with your namespace if different, and your-app-name with the name of your application. step Update code and view security insights .

Commands:
delete application your-app-name-app-of-apps -n rhtap 1