[Question] What does latest url referring to in ci.opensearch.org

[peterzhuamazon]

Hi All,

In ci.opensearch.org staging repo we use latest keyword to replace to the latest build number, e.g. 2400.

1. The latest url means pointing to the latest full 🟢 build (x64/arm64 tar/rpm all green).
2. The latest url means pointing to the latest build, no matter 🔴 or 🟢 status

https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.0.0-rc1/latest/linux/x64/tar/dist/opensearch/opensearch-2.0.0-rc1-linux-x64.tar.gz

We are having 1 right now, which means there is guaranteed to have a working tarball with latest, but not always the latest code.
This means, in 2.0.0-rc1 right now due to rpm failure, there is no latest url available yet for CI to use, even though tarball is built already.

Since there are a lot of plugin repo CIs use latest , if we go with 2 it might break CIs more often if any of tar/rpm build goes red.

Thanks.

[peterzhuamazon]

Old latest issue when we 1st implement it:
#1492

[dtaivpp]

I believe latest should refer to the latest stable and supported release. RC1, Alpha, and Beta releases should require users to have to explicitly opt-in (by manually selecting a version). This I have come expect when using the use the latest tag from any other projects.

[joshuali925]

since this is ci.opensearch (as opposed to artifacts.opensearch) i wouldn't expect latest to be stable and supported

even though tarball is built already

If a red tarball breaks downstream CIs then I would prefer option 1, otherwise i would prefer option 2 as currently reports-scheduler CI is broken because upstream rc1 missing opensearch-project/reporting#341

[peterzhuamazon]

@dtaivpp You misunderstood as this latest is only used for ci staging repo.
In production we will not use latest url.

Thanks.

[peternied]

The latest url means pointing to the latest full 🟢 build (x64/arm64 tar/rpm all green).

+1

If there is a failure, assets that were available are not longer present, that is not very useful for automated processes.

In the use case of the security plugin, opensearch-min is used to install the security plugin and verify service still comes up. We had issues in the past where we broke the distribution build and it wasn't discovered until after a week.

[dtaivpp]

@peterzhuamazon I am so glad I misunderstood! haha that would have been a bad UX 😅

[peterzhuamazon]

@peterzhuamazon I am so glad I misunderstood! haha that would have been a bad UX 😅

Sorry that my original description is not clear enough so I added some context now.
Thanks.

[amitgalitz]

The latest url means pointing to the latest full 🟢 build (x64/arm64 tar/rpm all green).

I think this makes more sense because it will take a lot of the usefulness out of latest if I am not sure if this build was successful or not and hence not being 100% sure what failed on the build that was fetched.

[dblock]

1. The latest url means pointing to the latest full 🟢 build (x64/arm64 tar/rpm all green).

I prefer this definition. Successfully compiled code that doesn't pass all tests, aka doesn't work (🔴) is not very useful and will yield too many false positives downstream when consumed.

[peterzhuamazon]

* What went wrong:
A problem occurred evaluating root project 'opensearch-index-management'.
> Can't get https://ci.opensearch.org/ci/dbc/distribution-build-opensearch/2.0.0-rc1/latest/linux/x64/builds/opensearch/plugins/opensearch-job-scheduler-2.0.0.0-rc1.zip to /tmp/tmpbpozmgws/index-management/src/test/resources/job-scheduler/opensearch-job-scheduler-2.0.0.0-rc1.zip

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

IM code is trying to get latest JS zip to build IM, but in reality there is no successful build yet in 2.0.0-alpha1, thus no latest.
This has become a catch 22 now, so IM needs latest JS but JS is not able to get from latest because the pipeline is not even complete and will fail due to IM cannot find JS.

This is why I support using 2 as 1 cause the above failure.

@amitgalitz @praveensameneni @dblock @CEHENKLE

[amitgalitz]

@peterzhuamazon Although this problem surfaces in our use of latest and could be solved with option 2, I think this is related to the issue highlighted here: #1463 and a cleaner solution could be to publish snapshots for each successfully built plugin before waiting for the entire build to succeed. For now we can remove IM and AD from the build and add it back as was done to solve this type of problem in the past

[peterzhuamazon]

@peterzhuamazon Although this problem surfaces in our use of latest and could be solved with option 2, I think this is related to the issue highlighted here: #1463 and a cleaner solution could be to publish snapshots for each successfully built plugin before waiting for the entire build to succeed. For now we can remove IM and AD from the build and add it back as was done to solve this type of problem in the past

Have some conversation with @amitgalitz offline and we will try to resolve this issue with maven zips after 2.0.0.

[peterzhuamazon]

We will keep using the latest == latest success build for now.