Open dblock opened 2 days ago
Today, we include the manifest.yml
file in the bundle. For example, with Docker, you can run:
docker run -it --entrypoint bash opensearchstaging/opensearch:2.18.0@sha256:f311da085b968663fadf041bafc78b24dc21556f0726e625caf3560f7323a020 -c "cat /usr/share/opensearch/manifest.yml"
This command will provide all the information about the plugins (along with the specific commits used) that are part of the bundle. We can extend this to include an entry in the YAML file that indicates whether the build was complete and error-free, signaling a potential beta, demo, or release candidate.
Additionally, we could implement logic to include both the head_commit
along with the exiting commit_id
for each plugin, enabling us to track whether the previous version was included.
Another approach is to use the metrics cluster to store more detailed information for every OpenSearch core snapshot—such as the commit used, plugin details, plugin commit IDs, the head commit of each plugin, and whether any plugin build failed (using an older revision as a result). In this scenario, users could access a dashboard for a more detailed analysis. But the expectation here for the user is to go and see the dashboard.
Adding @getsaurabh02 @peterzhuamazon @gaiksaya
Is it possible to annotate/include text somewhere on dockerhub for these (a description)?
If not, a build dashboard would be very nice!
This command will provide all the information about the plugins (along with the specific commits used) that are part of the bundle. We can extend this to include an entry in the YAML file that indicates whether the build was complete and error-free, signaling a potential beta, demo, or release candidate.
This is helpful. It does require downloading the image, but will save time. I documented it in https://github.com/opensearch-project/opensearch-api-specification/pull/642
Is your feature request related to a problem? Please describe
Coming from https://github.com/opensearch-project/opensearch-api-specification/pull/639 a developer is trying to bump the snapshot build for 3.0 and 2.18 to a newer one. Then tests fail because that newer build does not have the SQL or the ISM plugin.
Describe the solution you'd like
A way to easily find the next "complete" distribution of OpenSearch 3.0 / 2.x / 2.18 / etc., or at least a way to see which plugins are included in any given docker image. I think as a consumer of any docker staging build I'd like to know:
Describe alternatives you've considered
Randomly pick new docker staging SHAs and keep retrying.
Additional context
https://github.com/opensearch-project/opensearch-build/issues/5091