-
Notifications
You must be signed in to change notification settings - Fork 140
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'main' into RHTAPWATCH-1248
- Loading branch information
Showing
14 changed files
with
145 additions
and
105 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,78 +1,117 @@ | ||
# build-definitions | ||
|
||
This repository contains components that are installed or managed by the managed CI and Build Team. | ||
This repository contains components that are managed by the Konflux Build Team. | ||
|
||
This includes default Pipelines and Tasks. You need to have bootstrapped a working appstudio configuration from (see `https://github.com/redhat-appstudio/infra-deployments`) for the dev of pipelines or new tasks. | ||
This includes default Pipelines and Tasks. You need to have bootstrapped a working Konflux configuration from (see `https://github.com/redhat-appstudio/infra-deployments`) for the dev of pipelines or new tasks. | ||
|
||
Pipelines and Tasks are delivered into App Studio via quay organization `konflux-ci/tekton-catalog`. | ||
Pipelines are bundled and pushed into repositories prefixed with `pipeline-` and tagged with `$GIT_SHA` (tag will be updated with every change). | ||
Tasks are bundled and pushed into repositories prefixed with `task-` and tagged with `$VERSION` where `VERSION` is the task version (tag is updated when the task file contains any change in the PR) | ||
Pipelines and Tasks are delivered into Konflux via the quay organization `konflux-ci/tekton-catalog`. | ||
Pipelines are bundled and pushed into repositories prefixed with `pipeline-` and tagged with `$GIT_SHA` (the tag will be updated with every change). | ||
Tasks are bundled and pushed into repositories prefixed with `task-` and tagged with `$VERSION`, where `VERSION` is the task version (the tag is updated when the task file contains any change in the PR) | ||
|
||
Currently a set of utilities are bundled with App Studio in `quay.io/konflux-ci/appstudio-utils:$GIT_SHA` as a convenience but tasks may be run from different per-task containers. | ||
Currently, a set of utilities is bundled with Konflux in `quay.io/konflux-ci/appstudio-utils:$GIT_SHA` as a convenience, but tasks may be run from different per-task containers. | ||
|
||
|
||
## Building | ||
|
||
Script `hack/build-and-push.sh` creates bundles for pipelines, tasks and create appstudio-utils image. Images are pushed into your quay.io repository. You will need to set `QUAY_NAMESPACE` to use this feature and be logged into quay.io on your workstation. | ||
Once you run the `hack/build-and-push.sh` all pipelines will come from your bundle instead of from the default installed by gitops into the cluster. | ||
The script `hack/build-and-push.sh` creates bundles for pipelines, tasks and the `appstudio-utils` image. Images are pushed into your quay.io repository. You will need to set `QUAY_NAMESPACE` to use this feature and be logged into quay.io on your workstation. | ||
Once you run the `hack/build-and-push.sh`, all pipelines will come from your bundle instead of the default one installed by GitOps into the cluster. | ||
|
||
> **Note** | ||
> | ||
> If you're using Mac OS, you need to install [GNU coreutils](https://formulae.brew.sh/formula/coreutils) before running the `hack/build-and-push.sh` script: | ||
> If you're using macOS, you need to install [GNU coreutils](https://formulae.brew.sh/formula/coreutils) before running the `hack/build-and-push.sh` script: | ||
> ```bash | ||
> brew install coreutils | ||
> ``` | ||
There is an option to push all bundles to a single quay.io repository (this method is used in PR testing). It is used by setting `TEST_REPO_NAME` environment variable. Bundle names are then specified in the container image tag, i.e. `quay.io/<quay-user>/$TEST_REPO_NAME:<bundle-name>-<tag>` | ||
There is an option to push all bundles to a single quay.io repository (this method is used in PR testing). It is used by setting a `TEST_REPO_NAME` environment variable. Bundle names are then specified in the container image tag, i.e., `quay.io/<quay-user>/$TEST_REPO_NAME:<bundle-name>-<tag>` | ||
### Pipelines | ||
The pipelines can be found in the `pipelines` directory. | ||
- `core-services`: contains pipeline for the CI of Stonesoup core services e.g. application-service and build-service. | ||
- `template-build`: contains common template used to generate `docker-build`, `fbc-builder`, `java-builder` and `nodejs-builder` pipelines | ||
- `core-services`: contains pipelines for the CI of Konflux core services e.g., `application-service` and `build-service`. | ||
- `template-build`: contains common template used to generate `docker-build`, `fbc-builder`, `java-builder` and `nodejs-builder` pipelines. | ||
### Tasks | ||
The tasks can be found in the `tasks` directories. Tasks are bundled and used by bundled pipelines. Tasks are not stored in the Cluster. | ||
For quick local innerloop style task development, you may install new Tasks in your local namespace manually and create your pipelines as well as the base task image to test new function. Tasks can be installed into local namespace using `oc apply -k tasks/appstudio-utils/util-tasks`. | ||
The tasks can be found in the `tasks` directories. Tasks are bundled and used by bundled pipelines. Tasks are not stored in the cluster. | ||
For quick local inner-loop-style task development, you may install new Tasks in your local namespace manually and create your pipelines, as well as the base task image, to test new functionality. Tasks can be installed into the local namespace using `oc apply -k tasks/appstudio-utils/util-tasks`. | ||
There is a container which is used to support multiple set of tasks called `quay.io/konflux-ci/appstudio-utils:GIT_SHA` , which is a single container which is used by multiple tasks. Tasks may also be in their own container as well however many simple tasks are utilities and will be packaged for app studio in a single container. Tasks can rely on other tasks in the system which are co-packed in a container allowing combined tasks (build-only vs build-deploy) which use the same core implementations. | ||
There is a container used to support multiple sets of tasks called `quay.io/konflux-ci/appstudio-utils:GIT_SHA`. This is a single container used by multiple tasks. Tasks may also be in their own containers as well. However, many simple tasks are utilities and will be packaged for Konflux in a single container. Tasks can rely on other tasks in the system, which are co-packed in a container, allowing combined tasks (build-only vs. build-deploy) that use the same core implementations. | ||
Shellspec tests can be run by invoking `hack/test-shellspec.sh`. | ||
### StepActions | ||
The StepActions can be found in the `stepactions` directory. StepActions are not yet bundled. | ||
## Release | ||
Release is done by (better leave it to the [push pipeline](.tekton/push.yaml)): | ||
Take a look at the [Tekton documentation](https://tekton.dev/docs/pipelines/stepactions/) for more information about StepActions. | ||
```bash | ||
for quay_namespace in redhat-appstudio-tekton-catalog konflux-ci/tekton-catalog; do | ||
QUAY_NAMESPACE=$quay_namespace BUILD_TAG=$(git rev-parse HEAD) hack/build-and-push.sh | ||
done | ||
``` | ||
The StepActions can be found in the `stepactions` directory. StepActions are not yet bundled. | ||
### Versioning | ||
When the task update changes the interface (eg. change of parameters, workspaces or results names) then a new version of the task should be created. The folder with the new version must contain `MIGRATION.md` with instructions on how to update the current pipeline file in user's `.tekton` folder. | ||
When a task update changes the interface (e.g., change of parameters, workspaces or results names), a new version of the task should be created. The folder with the new version must contain `MIGRATION.md` with instructions on how to update the current pipeline file in user's `.tekton` folder. | ||
Adding a new parameter with a default value does not require the task version increase. | ||
Adding a new parameter with a default value does not require a task version increase. | ||
Task version increase must be approved by Project Manager. | ||
## Local development | ||
Tasks can have a TA (Trusted Artifact) version. | ||
The recommended workflow is to only edit the base version and let the other versions get generated automatically. | ||
``` | ||
./hack/generate-ta-tasks.sh | ||
``` | ||
Buildah also has a remote version, which can be generated with: | ||
``` | ||
./hack/generate-buildah-remote.sh | ||
``` | ||
## Testing | ||
Script `./hack/test-builds.sh` creates pipelines and tasks directly in current namespace and executes there test builds. By setting the environment variable `QUAY_NAMESPACE` the images will be pushed into user's quay repository, in that case creation of secret named `redhat-appstudio-staginguser-pull-secret` is required. | ||
|
||
Script `./hack/test-build.sh` provides way to test on custom git repository and pipeline. Usage example: `./hack/test-build.sh https://github.com/jduimovich/spring-petclinic java-builder`. | ||
### Prerequisites | ||
- Provisioned cluster with sufficient resources | ||
- Deployed Konflux on the cluster (see [infra-deployments](https://github.com/redhat-appstudio/infra-deployments)) | ||
1. Set up the image repository | ||
PipelineRuns attempt to push to cluster-internal registry `image-registry.openshift-image-registry.svc:5000` by default. | ||
For testing, you will likely want to use your own Quay repository. | ||
Specify the Quay repository using the `QUAY_NAMESPACE` environment variable in the format `OWNER/REPOSITORY_NAME`. | ||
2. Set up the `redhat-appstudio-staginguser-pull-secret` | ||
- Log in to `quay.io` using your credentials: | ||
``` | ||
podman login quay.io | ||
``` | ||
This will create an `auth.json` file in `${XDG_RUNTIME_DIR}/containers/auth.json`, which you will use to create a secret in the cluster. | ||
- Create the pull secret in you cluster: | ||
``` | ||
oc create secret docker-registry redhat-appstudio-staginguser-pull-secret --from-file=.dockerconfigjson=${XDG_RUNTIME_DIR}/containers/auth.json | ||
``` | ||
- Link the secret to your service account: | ||
``` | ||
oc secrets link appstudio-pipeline redhat-appstudio-staginguser-pull-secret | ||
``` | ||
3. Run the tests | ||
- To test a custom Git repository and pipeline, use `./hack/test-build.sh`. | ||
Usage example: | ||
``` | ||
QUAY_NAMESPACE=OWNER/REPOSITORY_NAME ./hack/test-build.sh https://github.com/jduimovich/spring-petclinic java-builder`. | ||
``` | ||
- To run tests on predefined Git repositories and pipelines, use: | ||
``` | ||
QUAY_NAMESPACE=OWNER/REPOSITORY_NAME ./hack/test-builds.sh | ||
``` | ||
- Shellspec tests can be run by invoking: | ||
``` | ||
./hack/test-shellspec.sh` | ||
``` | ||
### Compliance | ||
Task definitions must comply to [Enterprise Contract](https://enterprisecontract.dev/) policies. | ||
Currently, there are two policy configurations. The [all-tasks](./policies/all-tasks.yaml) policy | ||
configuration applies to all Task definitions, while the [build-tasks](./policies/build-tasks.yaml) | ||
policy configuration applies only to build Task definitions. A build Task, i.e. one that produces a | ||
container image, must abide to both policy configurations. | ||
Task definitions must comply with the [Enterprise Contract](https://enterprisecontract.dev/) policies. | ||
Currently, there are two policy configurations. | ||
- The [all-tasks](./policies/all-tasks.yaml) policy | ||
configuration applies to all Task definitions | ||
- The [build-tasks](./policies/build-tasks.yaml) | ||
policy configuration applies only to build Task definitions. | ||
A build Task, i.e., one that produces a | ||
container image, must abide by both policy configurations. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
# Task generator | ||
Task generator is a tool used for generating various versions of tasks. | ||
|
||
## Buildah remote task generation | ||
The Buildah task builds source code into a container image and pushes the image into container registry using the Buildah tool. | ||
While the standard Buildah task runs directly on the cluster, the remote task is run on a remote host. | ||
This must be used in combination with the Multi Arch Controller, which provides the credentials and host name used to perform the build. | ||
|
||
The remote versions of the Buildah task are programmatically generated by this script from the buildah task to keep them in sync. The generated remote tasks should not be manually modified. | ||
|
||
### Arguments | ||
- `buildah-task` - The location of the buildah task YAML file (required) | ||
- `remote-task` - The location of the buildah-remote task YAML file to overwrite (required) | ||
- `task-version` - The version of the task to overwrite, e.g. `0.2` (required) | ||
|
||
Example usage: | ||
``` | ||
go run remote/main.go \ | ||
--buildah-task ../task/buildah/0.2/buildah.yaml \ | ||
--remote-task ../task/buildah-remote/0.2/buildah-remote.yaml \ | ||
--task-version 0.2 | ||
``` | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.