Snow-3859269 migrate regress test

[sfc-gh-jzeng]

---

1. Which Jira issue is this PR addressing?

Fixes SNOW-3859269

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
     • If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am adding new credentials
   • I am adding a new dependency
   • If this is a new feature/behavior, I'm adding the Local Testing parity changes.
   • I acknowledge that I have ensured my changes to be thread-safe.
   • If adding any arguments to public Snowpark APIs or creating new public Snowpark APIs, I acknowledge that I have ensured my changes include AST support.

This PR only touches .github/workflows/, so it adds no tests, logging, telemetry, credentials, or dependencies.

3. Please describe how your code solves the related issue.

Step one of SNOW-3859269: this only adds the GitHub Actions workflow. The Jenkins job SnowparkPythonSnowflakePythonClientRegressRunner is untouched and still running. Retiring it, and removing it from the release-validation fan-out in jenkins_utils, is a separate PR once this has run for a few nights.

That job runs the snowpark suite against the connector's unreleased main branch, so a connector change that breaks snowpark shows up before the connector ships. On Jenkins it connects to a preprod account whose parameters can differ from prod, so a red build was often an environment difference rather than a real regression, and its definition lived in a different repo from the code it tests.

The line to review closely: daily_connector_regress.yml runs tox -e notdoctest-pandascap-pyarrowcap, identical to what scripts/jenkins_regress.sh runs today. jenkins_regress.sh has no test list of its own and delegates everything to tox.ini, so that string is the whole guarantee that coverage matches the Jenkins job. Editing it changes coverage silently.

The workflow checks out the connector at main, builds a wheel, and sets snowflake_path to it, which is all scripts/tox_install_cmd.sh needs. Nothing under src/ or tests/ changes, and no new secrets are needed: it reuses decrypt_parameters.sh and PARAMETER_PASSWORD, which is also what lands the run on the same prod account as daily_precommit.yml. That account change is the actual fix for the drift.

It runs nightly at 06:00 UTC and on workflow_dispatch. trigger_daily_tests_on_branch.yml gains a fifth entry so release validation dispatches it alongside the four existing daily workflows.

The three assert steps exist because the bad outcome here is a green run that tested the released connector instead of main: the wheel has to carry a cp310 tag, contain the nanoarrow .so, and be the one the tests actually imported. Two things deliberately differ from the other daily workflows, both commented in the file: the env resolves to -n logical rather than -n 6, because a daily* env would change the env name and would also drop --reruns 5 (precommit.yml already runs this env on the same runner size), and no junit artifact is uploaded, matching the other workflows here which upload coverage instead.

---

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[sfc-gh-jzeng]

I have read the CLA Document and I hereby sign the CLA

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.26%. Comparing base (e7d77e7) to head (03ed427).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4304   +/-   ##
=======================================
  Coverage   95.26%   95.26%           
=======================================
  Files         171      171           
  Lines       44720    44720           
  Branches     7676     7676           
=======================================
  Hits        42604    42604           
  Misses       1299     1299           
  Partials      817      817           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sfc-gh-yuwang]

I have two questions:

1. is there a way to test the added action before merge?
2. how long does this job usually take?

[sfc-gh-jzeng]

I have two questions:

1. is there a way to test the added action before merge?
2. how long does this job usually take?

1. The action/workflow can only be triggered after the definition .yml is merged. However, after merged, we can manually trigger it to see how it goes, and then evaluate how it performs at its expected triggering time.
2. Observed from the Jenkins job history, a typical one would take 1-2 hours. But in some cases, it would take over 10 hours with several false-positive failures. This is also the motivation for migrating from Jenkins to here.