|
1 |
| -= Workflow Reference Readme |
| 1 | += Workflow Reference |
2 | 2 |
|
3 |
| -This README serves as a guide to the GitHub Action workflows included in this repository. It outlines the purpose and functionality of each workflow, detailing their role in the CI and release processes. Additionally, this document provides an overview of the scripts and actions utilized in these workflows, offering insights into how they work together in SCDF's CI/CD pipeline. |
| 3 | +This README serves as a guide to the GitHub Action workflows included in this repository. |
| 4 | +It outlines the purpose and functionality of each workflow, detailing their role in the CI and release processes. |
| 5 | +Additionally, this document provides an overview of the scripts and actions utilized in these workflows, offering insights into how they work together in SCDF's CI/CD pipeline. |
4 | 6 |
|
5 | 7 | This document is a work in progress, and as various workflows are updated, the documentation will be revised to reflect both existing and new behaviors.
|
6 | 8 |
|
@@ -41,10 +43,13 @@ This document is a work in progress, and as various workflows are updated, the d
|
41 | 43 | Part of the release and CI process involves creating and pushing images to a registry (such as DockerHub) for the Dataflow server, Skipper server, CTR app, and other components.
|
42 | 44 | This process is managed by the `build-images` (build-images.yml) workflow. While the `build-images` workflow is typically not run independently, it is invoked by other workflows that handle CI builds and releases.
|
43 | 45 | The `build-images` workflow determines which images to create based on the `images.json` file.
|
44 |
| -This file contains metadata on the primary SCDF components that need to have an associated image. Each entry specifies the location (directory) where the jar can be found, jar name, and image name for each artifact that will be used to construct the image. |
| 46 | +This file contains metadata on the primary SCDF components that need to have an associated image. |
| 47 | +Each entry specifies the location (directory) where the jar can be found, jar name, and image name for each artifact that will be used to construct the image. |
45 | 48 | For each entry in the `images.json` file, the workflow calls the `build-image.sh` script, which retrieves the jar, builds the image, and then pushes it to the registry.
|
46 | 49 |
|
47 |
| -SCDF also provides images for external applications that support some of the optional features that are offered by dataflow. These include Grafana and Prometheus local. These images are created and pushed using the docker/build-push-action@v2 action. |
| 50 | +SCDF also provides images for external applications that support some of the optional features that are offered by dataflow. |
| 51 | +These include Grafana and Prometheus local. |
| 52 | +These images are created and pushed using the docker/build-push-action@v2 action. |
48 | 53 |
|
49 | 54 | === Scripts used to build images
|
50 | 55 | As mentioned above, the `build-image.sh` script is responsible for building the specified image based on the parameters provided and then pushing the image to Dockerhub.
|
|
60 | 65 | ```
|
61 | 66 |
|
62 | 67 | There is an optional `DEFAULT_JDK` environment variable that allows you to set the JDK version for the default image created.
|
63 |
| -If not the script will set it to its current setting (which as of the writing of this document is `17`) |
| 68 | +If not the script will set it to its current setting (which as of the writing of this document is `17`). |
64 | 69 |
|
65 | 70 | NOTE: When new releases of Java are available and are compliant with the SCDF release, they need to be added to the `build-image.sh` script.
|
66 | 71 |
|
0 commit comments