Pin GitHub Actions to full-length commit SHAs to unblock CI by RyanL1997 · Pull Request #79 · opensearch-project/sql-cli

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 · 2026-08-03T18:18:43Z

Description

CI is completely broken on 1.0-legacy. Every workflow here references actions by tag or branch, and the org now requires full-length commit SHA pins, so jobs fail during Set up job — before checkout, before any code runs:

The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and
actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all
actions must be pinned to a full-length commit SHA.

The actions tim-actions/get-pr-commits@v1.1.0 and tim-actions/dco@v1.1.0 are not allowed
in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA.

That takes out both the DCO check and the test-and-build job on every PR targeting this branch, so nothing can be merged here with green CI. This is independent of any code change — it hits PRs whose diff doesn't touch .github/ at all.

This pins all 13 action references to full SHAs, keeping the tag as a trailing comment in the usual @<sha> # <tag> form.

Where the SHAs come from

main is already SHA-pinned, so wherever it references the same action, this PR reuses main's exact SHA to keep the two branches consistent:

Action	SHA	Source
`tim-actions/get-pr-commits`	`55b867b9…` # v1.1.0	matches `main`
`tim-actions/dco`	`f2279e6e…` # v1.1.0	matches `main`
`release-drafter/release-drafter`	`09c613e2…` # v5	matches `main`
`actions/checkout` (link-checker)	`ee0669bd…` # v2	matches `main`
`lycheeverse/lychee-action`	`6da1d14f…` # master	matches `main`
`actions/checkout` (build)	`f43a0e5f…` # v3	matches `main`
`actions/setup-python`	`7f4fc3e2…` # v4	matches `main`
`actions/upload-artifact`	`ea165f8d…` # v4	matches `main` (see below)
`actions/github-script`	`d7906e4a…` # v6	resolved for the tag in use
`nick-fields/retry`	`14672906…` # v2	resolved for the tag in use
`tibdex/github-app-token`	`1901dc7d…` # v1.5.0	resolved for the tag in use
`VachaShah/backport`	`28c49d91…` # v1.1.4	resolved for the tag in use
`SvanBoxel/delete-merged-branch`	`2b5b058e…` # main	resolved from `main` HEAD

Every SHA was verified to resolve in its source repository before being written in.

One deliberate version change

actions/upload-artifact goes v3 → v4, matching main. v3 of the artifact actions was retired, so pinning v3's SHA would satisfy the org policy and still fail at runtime. The build job has a single matrix combination (python 3.8 × opensearch latest), so v4's unique-artifact-name requirement is already satisfied without renaming anything.

Everything else keeps its current major version — this is a pinning change, not an upgrade sweep.

What is not changed

The python-version: [3.8] matrix is untouched. I checked the actions/python-versions manifest and setup-python still publishes 3.8.18 builds for ubuntu-24.04, so 3.8 is not the problem here.
No workflow logic, trigger, step or with: input was modified.
add-untriaged.yml uses CRLF line endings; those are preserved, so its diff is the single uses: line rather than a whole-file rewrite.

Issues Resolved

None filed — surfaced while working on #78, whose CI failed for this reason rather than anything in its diff.

Testing

Diff is exactly the pins: 13 insertions / 13 deletions across 7 files, one line per action reference.
No unpinned references remain: grep -rn "uses:" .github/workflows/ | grep -vE "@[0-9a-f]{40} #" returns nothing.
SHA validity: each of the 13 SHAs confirmed to exist in its repo via repos/{owner}/{repo}/commits/{sha}.
YAML validity: all 7 workflow files re-parsed with yaml.safe_load and confirmed to still contain a jobs key.

The real verification is CI on this PR — if the pins are right, the DCO and build jobs should get past Set up job for the first time.

Check List

New functionality includes testing.
- All tests pass, including unit test, integration test and doctest
New functionality has been documented.
- New functionality has javadoc added
- New functionality has user manual doc added
Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Update: second commit — pinned test container + de-brittled explain assertions

With the pins in place CI reached the test step for the first time in roughly two years, and tests/test_main.py::TestMain::test_explain failed (1 failed, 27 passed, 2 skipped):

Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false)
Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null,
searchAfter=null, searchResponse=null)

This is pre-existing rot, not a regression from the pinning commit. The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024 (last touched in #30), while the workflow runs against opensearchproject/opensearch:latest — an unpinned, always-moving tag. The SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes", and dropped "searchDone".

1. Pinned the container to 3.7.0. That is what :latest currently resolves to — verified by comparing registry manifest digests (sha256:44ba7ea5… matches the 3.7.0 tag and no other). The test environment now stops moving underfoot, and a comment on the matrix warns that bumping it may require updating the expectations.

2. Stopped asserting on the full request string. The plan structure is still asserted exactly — operator names, projected fields, empty scan children. The request string is now checked only for what this test is actually about: the target index, the LIMIT 150 the query asked for, and the projected source field.

Verified the relaxed assertion is not simply re-pinned to today's server:

Input	Result
Observed OpenSearch 3.7.0 output	passes
Original 2024 server output	passes
Wrong index name	fails (as it should)
Wrong `LIMIT` / size	fails (as it should)

So it tolerates server-representation drift while still catching the things the assertion was there to catch.

Local pytest tests/ remains 25 passed, 5 skipped; test_main.py compiles and the workflow YAML still parses.

Every workflow on this branch referenced actions by tag or branch. The org now requires actions to be pinned to a full-length commit SHA, so all jobs fail during "Set up job" before checkout ever runs: The actions actions/checkout@v3, actions/setup-python@v4, nick-fields/retry@v2, and actions/upload-artifact@v3 are not allowed in opensearch-project/sql-cli because all actions must be pinned to a full-length commit SHA. That takes out the DCO check and the test-and-build job on every pull request against 1.0-legacy, so nothing can be merged here with green CI. Pins all 13 action references to full SHAs, keeping the tag as a trailing comment. Where the main branch already pins the same action, the SHA matches main so the two branches stay consistent. One version change: actions/upload-artifact moves v3 -> v4, matching main. v3 of the artifact actions was retired and pinning its SHA would satisfy the policy while still failing at runtime. The build job has a single matrix combination, so the unique-artifact-name requirement in v4 is already met. No other behaviour changes: the Python 3.8 matrix is unchanged (setup-python still publishes 3.8.18 for ubuntu-24.04) and no workflow logic was touched. All seven workflow files were checked to still parse as valid YAML. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

With the action pins in place, CI reaches the test step for the first time in roughly two years and immediately fails on tests/test_main.py::test_explain: Expected: ..."_source":{"includes":["a"],"excludes":[]}}, searchDone=false) Actual: ..."_source":{"includes":["a"]}}, pitId=null, cursorKeepAlive=null, searchAfter=null, searchResponse=null) The test hardcodes an expected OpenSearchQueryRequest.toString() captured in September 2024, while the workflow runs against opensearchproject/opensearch :latest -- an unpinned, always-moving tag. The server-side SQL plugin has since added PIT support (pitId, cursorKeepAlive, searchAfter, searchResponse), stopped emitting "excludes" and dropped "searchDone", so the assertion was guaranteed to rot. Dead CI simply hid it. Two changes: 1. Pin the container to 3.7.0, which is what :latest currently resolves to (verified by comparing registry manifest digests), so the test environment stops moving underfoot. 2. Stop asserting on the full request string. The plan structure is still checked exactly -- operator names, projected fields, empty scan children -- and the request is checked only for the parts that carry meaning here: the target index, the LIMIT 150 that the query asked for, and the projected source field. The relaxed assertion still fails on a wrong index or a wrong limit, and it passes against both the 3.7.0 output and the original 2024 output, so it is not merely re-pinned to today's server. This keeps the branch green without coupling the suite to server internals it was never trying to test. Signed-off-by: Jialiang Liang <jiallian@amazon.com>

RyanL1997 requested review from MaxKsyunz, Swiddis, YANG-DB, Yury-Fridlyand, anirudha, dai-chen, derek-ho, joshuali925, kavithacm, mengweieric, penghuo, ps48 and seankao-az as code owners August 3, 2026 18:18

Swiddis approved these changes Aug 4, 2026
View reviewed changes

Swiddis merged commit deb5146 into opensearch-project:1.0-legacyAug 4, 2026
4 checks passed