Skip SVN operations in CI environment

[potiuk]

The release candidate commands were failing in CI because SVN operations require credentials and network access to the ASF SVN repository.

This change detects when running in CI (via CI environment variable) and simulates SVN operations instead of executing them:

• svn checkout: creates empty directory structure
• svn mkdir: uses regular mkdir
• svn add/commit/rm: prints simulation messages

This allows the release candidate workflow to be validated in CI without requiring SVN access, while preserving full functionality in production.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Copilot with auto model following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[amoghrajesh]

Yeah not a bad idea

[amoghrajesh]

Breeze unit tests will need fixing though

[potiuk]

Breeze unit tests will need fixing though

Yeah. My favourite AI was on it :)

[potiuk]

Hey @shahar1 -> also added a few small things:

• changed the marker to integration_tests - we already have integration marker in Airflow and it might be confusing to use the same marker here (especially that the integration marker in airflow takes integration name as parameter
• I move the tests to integration_tests package (easier to find them)
• added description of the integration_tests to README.md
• detection of tools is done by running --version with them (which is generally deprecated for reasons connected to Windows usage and running nnn --version is generally more portable).
• also it turns out that svn checkout -r REVISION PATH will not work if the PATH does not exist in HEAD - I got this error when running it locally:

SKIPPED [1] tests/integration_tests/test_airflow_release_validator_integration.py:208: Failed to checkout Airflow SVN: svn: E160013: '/repos/dist/!svn/rvr/82376/dev/airflow/3.1.6rc1' path not found 

So instead when "real" SVN is used (locally) - it checks which version is available in SVN for airflow and task-sdk - and uses the revision it finds.

For CI running, it uses some "simulated" versions and creates the folder.

[potiuk]

It's been way more than initially anticipated :D

[shahar1]

Hey @shahar1 -> also added a few small things:

• changed the marker to integration_tests - we already have integration marker in Airflow and it might be confusing to use the same marker here (especially that the integration marker in airflow takes integration name as parameter
• I move the tests to integration_tests package (easier to find them)
• added description of the integration_tests to README.md
• detection of tools is done by running --version with them (which is generally deprecated for reasons connected to Windows usage and running nnn --version is generally more portable).
• also it turns out that svn checkout -r REVISION PATH will not work if the PATH does not exist in HEAD - I got this error when running it locally:

SKIPPED [1] tests/integration_tests/test_airflow_release_validator_integration.py:208: Failed to checkout Airflow SVN: svn: E160013: '/repos/dist/!svn/rvr/82376/dev/airflow/3.1.6rc1' path not found 

So instead when "real" SVN is used (locally) - it checks which version is available in SVN for airflow and task-sdk - and uses the revision it finds.

For CI running, it uses some "simulated" versions and creates the folder.

Great, thanks for all of that!

[potiuk]

Great, thanks for all of that!

Claude was helpful :)

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5953b82 v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.