Notifications/Hooks to different systems.

[saratvemulapalli]

No description provided.

[camerski]

The test system will need a way to get metadata about bundle builds.

First stab at a proposal:

1. Bundle builds have a unique ID and are stored in S3, under a path like /path/to/bundles/<buildnumber>/<files>.
2. <files> contains all the components of the bundle (jars, plugin zips, etc) and a manifest file.
3. The build system stores the bundle build in S3, then sends an SNS notification to the test system. The SNS message contains the bundle build ID and a link to the manifest URL. A simple JSON document would suffice: {"buildid":<number>, "manifest":"path"}
4. The manifest.yml looks like this:

schema-version: 1.0
product:
  type: opensearch | dashboards
  version: major.minor.patch
  platform: x64 | arm64
components:
  - name: string
    repository: github url
    commit: hash
    original-ref (optional): branch or tag name
  ...
build:
  build-id: string
  location: s3://path/to/<build-id>

The schema-version field is to allow for evolving the manifest format over time.

The product element provides basic information about what this bundle represents.

The test system can choose which bundle test suites to run based on the product, build information, and components. For example, a snapshot opensearch-min bundle will have a fairly small set of tests (no plugins, no need for a full set of expensive performance tests for a snapshot build), whereas an opensearch non-snapshot bundle with 15 components will require a much larger test suite, including tests for each component.

Component information is included both for reproducibility and to inform the test system which packages need to be checked out in order to run per-component integration tests.

When the test system receives a notification it can load the manifest and start an appropriate test pipeline for the bundle. Test results will be recorded in a subfolder of the path specified in build/location.

[Out of scope] When a test run concludes, an SNS notification could be published (format TBD) so interested parties can react.

[Out of scope] Dashboards. We will want to extend the system to test Dashboards, but this is out of scope right now.

[saratvemulapalli]

I like this.
Couple of questions (Trying to understand):

1. How are dependencies listed? Would they be another product?
2. If yes to 1. How do we know which build-id was used to build the bundle for a product. i.e Probably the inner question is, is the build-id the id for bundle or for each product artifact the bundle was built out of?

[camerski]

By dependencies, do you mean the individual plugins? Those are captured in the components section, one entry per plugin plus one entry for the core opensearch component. Plugins are not standalone products.

[saratvemulapalli]

By dependencies, do you mean the individual plugins? Those are captured in the components section, one entry per plugin plus one entry for the core opensearch component. Plugins are not standalone products.

Yeah mostly plugins and libraries. That makes sense.

[mch2]

I wrote up a meta issue on our end to describe this e2e - #132.

In order for us to read and build this in a script we need to know the entry-point for each component to build & its output location. So we either include that as part of this manifest as input-command/output-dir properties or define standards in build.sh.

Another thought here, we need a way on the build end to know if a particular component has been cached. If it is then we will not build it or include it in artifacts for release. This is particularly useful for libs that may not have been updated. Something like -

schema-version: 1.0
product:
  type: opensearch | dashboards
  version: major.minor.patch
  platform: x64 | arm64
components:
  - name: string
    repository: github url
    commit: hash
    branch (optional): branch or tag name
    cached-version (optional): 1.0.0
  ...
build:
  build-id: string
  location: s3://path/to/<build-id>

[dblock]

nit: commit -> ref, standard git naming

[camerski]

commit needs to be named commit because it captures the actual commit ID that was used to build each component. It is not a generic git ref, because git refs (in particular, branch names) can point to different things over time. The branch field is a generic git ref and could be renamed to ref (or maybe original-ref) to capture the branch or tag name that the component was built from.

[peternied]

[Triage] When jenkins has been make public users/tools can subscribe via RSS feed to jobs of interest for them. If there are more specific workflows that cannot be supported we can look at individual feature requests.