Skip to content

Latest commit

 

History

History
158 lines (103 loc) · 5.43 KB

development.adoc

File metadata and controls

158 lines (103 loc) · 5.43 KB

Development

Requirements

Local Development

The repository has been setup to make it easy to test your changes locally with your own quay.io account.

Note
You need to be logged in to registry.redhat.com to be able to pull some required images. If you are using minikube you can do this via docker login registry.redhat.io. If you are running against an openshift cluster, the pipeline SA and all TaskRuns/PipelineRuns running under the pipeline SA have the credentials to registry.redhat.io available via the cluster install pull secret.

Ensure the environment variables (especially QUAY_USERNAME) have been configured as per the installation instructions.

Now run the following command to build the relevant images and deploy them to kube:

make dev
Note
If you see errors after running make dev for the first time this may be because the CRD’s have not completly installed in time. If you run ./deploy/development.sh again this should resolve the problem.
Warning
This will create private repositories by default, you will need to set them to public for the next step to work.

Once you have made these public on quay.io you should have a local build ready to go.

Note that you may need to restart the deployments after the repo has been made public:

kubectl rollout restart deployment hacbs-jvm-cache
kubectl rollout restart deployment hacbs-jvm-operator

Testing it out

You can test this out by running:

./hack/examples/run-sample-pipeline.sh

Once this has been run you should be able to observe the progress via:

tkn pr logs --last -f

This will show the initial build. Once it is complete you should be able to see a list of community dependencies that were used in the logs.

You should then be able to look at the artifactbuilds that the system has created to rebuild them:

kubectl get artifactbuilds

Once these have been created the system will run discovery pipelines to try and figure out how to build them. This is a Tekton TaskRun, so you can observe the progress by running:

tkn tr list

Once the discovery phase has been created then the system will create dependencybuild objects for all the builds that is knows how to do. You can view these with:

kubectl get dependencybuilds

These will also result in the creation of PipelinRun objects to attempt to do the builds:

tkn pr list

Once all this is complete you should be able to re-run the example build script and you will see that a lot less dependencies are reported as being community dependencies as the system has automatically rebuilt them.

Fine Grained Restarts

While developing you generally don’t want to rebuild everything. To just build a JVM based image you can run the following command from java-components directory that contains the project you want to build (or from the java-components directory itself if you want to build all of them):

mvn clean install -Dlocal

This will build the image and push it to Quay. For the golang based operator you can run:

make dev-image

For tasks that run as part of a pipeline this is all that is needed, for persistent services you need to restart the deployment:

kubectl rollout restart deployment hacbs-jvm-operator
kubectl rollout restart deployment hacbs-jvm-cache

Config changes can be made in the deploy directly and applied by running:

./deployment/base-development.sh

Testing

Running Option Tests Against PRs

You can trigger the following optional tests on a pull request:

Apicurio Registry

/test jvm-build-service-in-repo-apicurio-e2e

Self Build of the JVM Build Service

/test jvm-build-service-in-repo-jbs-e2e

RHTAP Quickstarts

/test jvm-build-service-in-repo-quickstarts-e2e

WildFly

/test jvm-build-service-in-repo-wildfly-e2e

Test JVM Build Service on an OpenShift cluster

The OpenShift E2E test is programmed to run a test with following steps:

  1. Create a new project in targeted OpenShift cluster and run the build pipeline which contains a link: ./hack/examples/maven-v0.2.yaml[Maven] task from this repo to build the link:./hack/examples/run-e2e-shaded-app .yaml[simple java test project]

  2. Make sure the pipeline succeeds and all related artifactbuilds and dependecybuilds (triggered after pipeline completion) finish successfully

  3. Check that all "contaminated" builds are resolved

  4. Verify that triggering a second build accesses dependencies that are cached from a previous build

  5. Verify that the correct JDK version is identified in dependencybuilds

  6. Check that maven/gradle logs/sources are found in rebuilt artifacts

Before running the test, you need to export couple of env vars that reference container images for the operator, cache and build-request-processor.

Also you need to specify your quay.io username that will be used for pushing rebuilt dependencies in a format: quay.io/$QUAY_USERNAME/test-images. Make sure the repo "test-images" exists in your account and is publicly available.

export QUAY_USERNAME=<your-quay-io-account-username>
export JVM_BUILD_SERVICE_IMAGE=
export JVM_BUILD_SERVICE_CACHE_IMAGE=
export JVM_BUILD_SERVICE_REQPROCESSOR_IMAGE=
./deploy/openshift-ci.sh
make openshift-e2e