This repo creates multiple images for delivery into the app studio platform.
Default pipelines are delivered into quay.io/redhat-appstudio/build-templates-bundle
Base Image for the ClusterTasks are in quay.io/redhat-appstudio/appstudio-utils

The versions for these images are maintained separately in each directory which leads to confusion
Options

1. We change the release build to build both images at the same version. This requires the cluster tasks which are defined in the app studio environment to get version bumped every time any new release occurs.
2. We write some update scripts which update the infra-deployment repository contents with the correct versions of the two (or more) images to prevent the wrong images updates.

I think we should do both -- and embed the automation in the .ci script for building and then installing new pipelines into app studio.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository.

• WARN: No docker auth found - returning

⚠ Dependency Lookup Warnings ⚠

• Renovate failed to look up the following dependencies: Failed to look up docker package registry.redhat.io/openshift4/ose-tools-rhel8, Failed to look up docker package registry.redhat.io/openshift4/ose-cli, Could not determine new digest for update (datasource: docker).

Files affected: .tekton/pull-request.yaml, task/init/0.1/init.yaml, task/s2i-java/0.1/s2i-java.yaml, task/s2i-nodejs/0.1/s2i-nodejs.yaml, task/summary/0.1/summary.yaml

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update quay.io/containerbuildsystem/cachi2 docker digest to 9036f59

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

redhat-appstudio/infra-deployments#53 (comment)

Acceptance Criteria

The following tekton manifests should consume pipeline definitions from https://quay.io/repository/redhat-appstudio/build-templates-bundle?tab=tags which are built off https://github.com/redhat-appstudio/build-definitions/tree/main/pipelines/build-templates-bundle

• https://github.com/redhat-appstudio/infra-deployments/tree/main/components/gitops/.tekton
• https://github.com/redhat-appstudio/infra-deployments/tree/main/components/has/.tekton

For RHTAS prodsec compliance, we have been asked to provide links to systems or documents where it is shown how SAST findings are analyzed and processed by the team. With the current Konflux configuration, it is not straightforward to do this. Snyk Code results are stored as pipeline results, but are not shipped anywhere else during a pipelinerun. It would be ideal for us if the snyk results could be published to snyk.io using the --report option for snyk code test. This feature appears to be in private beta, but it has been for about a year. Perhaps we could use it?

This is a request to include oras binaries in the appstudio-utils image from https://github.com/oras-project/oras/releases
Not sure if this is too experimental or if this is not the right place to include it but open to feedback.

I am trying to use the build-definitions with https://github.com/openshift-pipelines/pipelines-service.

With some fixes in pipelines-service (https://github.com/openshift-pipelines/pipelines-service/compare/main...guillaumerose:builddef?expand=1), the PR is triggered but I hit an issue: ClusterTask doesn't exist on KCP and all definitions are using them.
How could we solve that?

Events:
  Type     Reason         Age   From         Message
  ----     ------         ----  ----         -------
  Normal   Started        29s   PipelineRun  
  Warning  Failed         27s   PipelineRun  Pipeline /noop can't be Run; it contains Tasks that don't exist: Couldn't retrieve Task "openshift-client": the server could not find the requested resource (get clustertasks.tekton.dev openshift-client)
  Warning  InternalError  27s   PipelineRun  1 error occurred:
           * Couldn't retrieve Task "openshift-client": the server could not find the requested resource (get clustertasks.tekton.dev openshift-client)

Acceptance criteria:

Upon, merge to https://github.com/redhat-appstudio/build-definitions , everything inside https://github.com/redhat-appstudio/build-definitions/tree/main/pipelines/build-templates-bundle should be built into a new bundle as deemed relevant.

Implementation notes

• Add a /.tekon directory in https://github.com/redhat-appstudio/infra-deployments/tree/main/components/build
• Add manifests to setup a webhook that would be triggered from https://github.com/redhat-appstudio/build-definitions
• The pipeline that is run upon triggering the webhook should build the bundle and push to Quay https://quay.io/repository/redhat-appstudio/build-templates-bundle?tab=tags

In various contexts, we want to install packages into a sub directory of the root directory, and then use them as the root directory of a subsequent stage. Examples include:

• Creating a standard base image from a Containerfile
• Creating a bootc base image using rpm-ostree
• Creating a Flatpak runtime

In all of these cases, we really don't want to install into a bare directory - this will result in weirdness like redirections to /dev/null going into a actual file. The directory at least needs a skeleton /dev populated and would ideally have /proc and /sys as well.

There are two basic ways that this could be enabled:

• Allow running buildah build with --cap-add=all --security-opt=label=disable ; this is sufficient to allow the Containerfile to create its own mount namespace and populate the root directory itself.

• Instead specify the install directory as a task parameter, and have the buildah task add something like:

         --device=/dev/null:"$INSTALL_ROOT"/dev/null
         --device=/dev/random:"$INSTALL_ROOT"/dev/random
         --device=/dev/urandom:"$INSTALL_ROOT"/dev/urandom
         --device=/dev/zero:"$INSTALL_ROOT"/dev/zero
  

The advantage of this is that it is more flexible and satisfies some other needs for nested sandboxing¹. It may the only way that actually works for the bootc case [@cgwalters - is that right?]. On the other hand, the second approach is more obviously secure. ²