-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[POC] Universal Release Prototype for Data Prepper #1
Changes from all commits
a30d48b
0484f17
4400ba0
d0e2a56
1c89186
06156ad
70acff9
7e26662
10adfe0
f05b0ba
05b65ab
d8ae325
3f0a851
8cdefab
1cbe5a5
9f8cbd1
3922c55
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
# This workflow will build a Java project with Gradle | ||
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle | ||
|
||
name: Starts a data prepper release | ||
|
||
on: | ||
workflow_dispatch: | ||
|
||
jobs: | ||
r: | ||
runs-on: ubuntu-latest | ||
|
||
steps: | ||
- name: Set up JDK ${{ matrix.java }} | ||
uses: actions/setup-java@v1 | ||
with: | ||
java-version: ${{ matrix.java }} | ||
- name: Checkout Data-Prepper | ||
uses: actions/checkout@v2 | ||
- name: Grant execute permission for gradlew | ||
run: chmod +x gradlew | ||
- name: Build with Gradle | ||
run: ./gradlew build | ||
- name: Upload Coverage Report | ||
uses: codecov/codecov-action@v1 | ||
- name: Generate Javadocs | ||
run: ./gradlew javadoc | ||
|
||
## Upload the build artifact to s3 | ||
- name: Upload build artifacts | ||
uses: reggionick/s3-deploy@v3 | ||
with: | ||
folder: data-prepper-core/build/libs | ||
bucket: ${{ secrets.S3_BUCKET }} | ||
bucket-region: ${{ secrets.S3_BUCKET_REGION }} | ||
delete-removed: false | ||
|
||
## Create the docker image and upload it to data-prepper-staging, it houses continuous/nightly builds | ||
- name: Build the Docker image | ||
run: docker build . --file release/docker/Dockerfile --tag data-prepper:${{ VERSION }} | ||
|
||
## Add the distribution manifest static file to the release artifacts | ||
- name: Upload Jars to release | ||
id: upload_release_jars | ||
uses: softprops/action-gh-release@v1 | ||
with: | ||
upload_url: ${{ steps.create_release.outputs.upload_url }} | ||
asset_path: data-prepper-core/build/libs/data-prepper-core-${{ VERSION }}.tar.gz | ||
asset_name: data-prepper-core-${{ VERSION }}.tar.gz | ||
asset_content_type: application/tar+gzip | ||
|
||
## Create the distribution manifest that will be used | ||
- name: Create dist manifest | ||
run: | | ||
echo "---" > manifest.yml | ||
echo "schema-version: '2.0'" >> manifest.yml | ||
echo "build:" >> manifest.yml | ||
echo " - name: Data-Prepper" >> manifest.yml | ||
echo " version: ${{ VERSION }}" >> manifest.yml | ||
echo "artifacts:" >> manifest.yml | ||
echo " - location: https://${{ secrets.S3_BUCKET }}/data-prepper-core-${{ VERSION }}.tar.gz" >> manifest.yml | ||
echo "containers:" >> manifest.yml | ||
echo " - type: docker" >> manifest.yml | ||
echo " tag: data-prepper-staging/data-prepper:${{ VERSION }}" >> manifest.yml | ||
|
||
## Note for above artifacts, no platform / architecture is included because the artifacts are multi-platform/architecture | ||
|
||
## Create a pull request to commit the manifest version into the codebase | ||
- name: Create Pull Request | ||
uses: peter-evans/create-pull-request@v3 | ||
with: | ||
author: opensearch-ci-bot <[email protected]> | ||
commit-message: | | ||
Release manifest for ${{ VERSION }}. | ||
|
||
Signed-off-by: opensearch-ci-bot <[email protected]> | ||
delete-branch: true | ||
title: '[AUTO] Release manifest for ${{ VERSION }}.' | ||
body: | | ||
A release has been triggered with this manifest. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,104 @@ | ||
properties([ | ||
parameters([ | ||
string( | ||
name: 'DistManifestUrl', | ||
description: 'The url to distribution manifest for this release')]) | ||
]) | ||
|
||
lib = library( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please consider making this part of the pipeline instead. In this way, a team creating a stage can configure their pipeline with the desired source without having to change their stage file. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a good question towards what the 'minimum' started file is, for the moment I think I'd rather error on the side of caution and include these sections. We can always streamline later if we come up with a good way to synchronize them |
||
identifier: 'jenkins@uni-poc', | ||
retriever:modernSCM( | ||
[$class: 'GitSCMSource', | ||
remote: 'https://github.com/peternied/opensearch-build.git', | ||
traits: [gitBranchDiscovery()] | ||
]) | ||
) | ||
|
||
Map config = [ | ||
cleanup: { -> echo "Totally unneed clean for demo purposes"} | ||
] | ||
|
||
standardReleasePipeline(config) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Data Prepper team needs to create this stage. It is not maintained by opensearch-build. The Jenkinsfile for it will exist in the Data Prepper repository. |
||
def distManifest = new FakeDistManifest(fakeYmlFromUrl(params.DistManifestUrl)) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It appears that the distribution manifest is the major defining factor for the source project. How will the manifest work with different versions? Will it be parameterized? Right now, for Data Prepper, I'm expecting two possible parameters:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Excellent question, I hand waved over this for the POC. Little background, OpenSearch project will be built inside of many different build systems gradle, node or python. These all have different processes to create a distributable component, by using a common format to describe different kinds of artifacts, no matter how binaries or docker images or the-next-big-thing is created these workflows can still interact with them. Here is a snippet of 1.1 version with a OpenSearch distribution: ---
schema-version: '1.1'
build:
name: OpenSearch
version: 1.3.0
platform: linux
architecture: x64
location: https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/1.3.0/813/linux/x64/dist/opensearch/opensearch-1.3.0-linux-x64.tar.gz
id: '813'
components:
- name: OpenSearch
repository: https://github.com/opensearch-project/OpenSearch.git
ref: 1.x
commit_id: 02ca00fc7289cda1b87b34992a82b2b849a4b1a4
location: https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/1.3.0/813/linux/x64/builds/opensearch/dist/opensearch-min-1.3.0-linux-x64.tar.gz
- name: job-scheduler
repository: https://github.com/opensearch-project/job-scheduler.git
ref: main
commit_id: a67e734f5760af7225553bee17707f057c2af740
location: https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/1.3.0/813/linux/x64/builds/opensearch/plugins/opensearch-job-scheduler-1.3.0.0.zip
...
The distribution manifest is the 'trigger' to start a release, Jenkins access might not be required to release a new version, or the url to the manifest is all that is needed. The intent is that it is trivial to generate via any build system, including but not limited to a GitHub action with no other external systems.
The manifest contains the URIs of artifacts and container to publish, the different functions in the workflow will prepare/publish them as desired. The manifest should be pointing to static assets that will be transformed during a release operation. Allows for N kinds of assets split across platforms, architectures or what-not. So there would be a distribution manifest for each release with no parameterization. All that said we can build the generation for this quickly to make sure we've got the correct level of fidelity and clarity for everyone. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added a prototype of how the ---
schema-version: '2.0'
build:
- name: Data-Prepper
version: ${{ VERSION }}
artifacts:
- location: https://${{ secrets.S3_BUCKET }}/data-prepper-core-${{ VERSION }}.tar.gz
containers:
- type: docker
tag: data-prepper-staging/data-prepper:${{ VERSION }} |
||
|
||
def downloadPath = fakeDownloadArtifacts(distManifest) | ||
|
||
fakeSignArtifacts( | ||
artifactsPath: downloadPath, | ||
signatureType: '.sig', | ||
distributionPlatform: 'linux', | ||
) | ||
|
||
fakePublishToMaven( | ||
mavenArtifactsPath: "${downloadPath}/maven", | ||
autoPublish: true | ||
) | ||
|
||
fakePublishToArtifactRepositry( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are these the .tar.gz files? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes - they are described in the manifest that I hand-waved over |
||
productName: distManifest.product, | ||
version: distManifest.version, | ||
) | ||
|
||
fakeCopyDockerImage( | ||
sourceImagePath: distManifest.artifacts.containerReference, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Data Prepper release build will create a Docker image and upload it to our staging ECR registry. Data Prepper will not have a staging DockerHub registry. I want to be sure that this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This signature was based on existing functionality. We can make sure that it would work as either docker or ecr first sources |
||
destinationImagePath: "opensearchproject/${distManifest.product}:${distManifest.version}", | ||
destinationType: "docker", | ||
destinationCredentialIdentifier: "opensearch-docker-prod" | ||
) | ||
|
||
fakeCopyDockerImage( | ||
sourceImagePath: distManifest.artifacts.containerReference, | ||
destinationImagePath: "opensearchproject/${distManifest.product}:${distManifest.version}", | ||
destinationType: "ecr", | ||
destinationCredentialIdentifier: "opensearch-ecr-prod" | ||
) | ||
} | ||
|
||
///////////////////////////////////////////////////////////////////////////////////// | ||
// Fakes were written to make sure POC could be executed against jenkins environment | ||
|
||
class FakeDistManifest implements Serializable { | ||
// Additional contents need to be added to the dist manifest for | ||
// these parameters | ||
class Artifacts implements Serializable { | ||
String containerReference | ||
Artifacts(Map data) { | ||
this.containerReference = data?.containerReference | ||
} | ||
} | ||
|
||
Artifacts artifacts | ||
String product | ||
String version | ||
peternied marked this conversation as resolved.
Show resolved
Hide resolved
|
||
FakeDistManifest(Map data) { | ||
println "new DisManifest: ${data}" | ||
this.artifacts = new Artifacts(data?.artifacts) | ||
this.product = data?.product | ||
this.version = data?.product | ||
} | ||
} | ||
|
||
Map fakeYmlFromUrl(String url) { | ||
echo "ymlFromUrl: ${url}" | ||
return [:] | ||
} | ||
|
||
def fakeDownloadArtifacts(FakeDistManifest manifest) { | ||
echo "fakeDownloadArtifacts" | ||
} | ||
|
||
def fakeSignArtifacts(Map args) { | ||
echo "fakeSignArtifacts ${args}" | ||
} | ||
|
||
def fakePublishToMaven(Map args) { | ||
echo "fakePublishToMaven ${args}" | ||
} | ||
|
||
def fakePublishToArtifactRepositry(Map args) { | ||
echo "fakePublishToArtifactRepositry ${args}" | ||
} | ||
|
||
def fakeCopyDockerImage(Map args) { | ||
echo "fakeCopyDockerImage ${args}" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does it mean for a Jenkins stage to define parameters? I thought they had to be defined at the job/pipeline level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 'minimum' addressable unit for a release seems to be a distribution manifest. However this might not be a one-size-fits-all solution so I wanted to be sure that parameters could be added for other project types.
I believe its useful to see the parameter defined here as a property so its clear within the
standardReleasePipeline {...}
body code of this file that it can be accessed viaparams.DistManifestUrl