Skip to content

[CI] Add basic checks workflow with one job#2636

Closed
jbampton wants to merge 1 commit intoapache:mainfrom
jbampton:add-basic-check-workflow
Closed

[CI] Add basic checks workflow with one job#2636
jbampton wants to merge 1 commit intoapache:mainfrom
jbampton:add-basic-check-workflow

Conversation

@jbampton
Copy link
Member

Apache Airflow uses this same basic check:

https://github.com/apache/airflow/blob/3c5348fd05be80738c71eb075956f87e7d5fcec3/.github/workflows/basic-tests.yml#L293

We don't have much test coverage running on Windows.

Should be quick to run on the GitHub CI

refs apache/sedona#2753


From Google:

Testing git clone on Windows is essential because of how the operating system handles files differently than Linux or macOS. Since Git was originally designed for Linux, several "Windows-specific" behaviors can cause a clone to fail or corrupt the project if not properly configured.
The primary reasons for testing on Windows include:

  1. Line Ending Inconsistencies
  • The Issue: Windows uses Carriage Return + Line Feed (CRLF) for new lines, while Linux and macOS use just Line Feed (LF).
  • The Risk: Without testing, a clone might automatically convert all files to CRLF, which can break scripts (like .sh files) intended to run in Docker or cross-platform environments.
  • The Fix: Developers often use the git config --global core.autocrlf true setting to manage these conversions automatically.
  1. Case Sensitivity Conflicts
  • The Issue: The Windows file system is typically case-insensitive (e.g., README.md and readme.md are the same file), whereas Linux is case-sensitive.
  • The Risk: If a repository contains two files with the same name but different casing, cloning on Windows will result in a path collision. One file will overwrite the other, or the clone will fail with an error.
  • The Fix: Testing ensures that the repository structure is compatible with the core.ignorecase setting commonly used on Windows.
  1. File Path Length Limits
  • The Issue: By default, Windows has a "MAX_PATH" limit of 260 characters.
  • The Risk: Deeply nested projects (common in Node.js or Java) may fail to clone because the resulting file paths are too long for Windows to handle.
  • The Fix: Testing identifies if you need to enable git config --system core.longpaths true to bypass these limits. [6]
  1. Permission & Tooling Differences
  • Permissions: Windows does not use the same POSIX file permissions as Linux. This can lead to "executable" bits being lost or ignored after a clone.
  • SSH vs. HTTPS: Windows often requires specific credential managers or configurations for SSH keys that differ from Unix-based systems.
  • Network Performance: Features like "Receive Window Auto-Tuning" in Windows can sometimes cause git clone to be significantly slower or more prone to timing out than on other platforms.

Apache Airflow uses this same basic check:

https://github.com/apache/airflow/blob/3c5348fd05be80738c71eb075956f87e7d5fcec3/.github/workflows/basic-tests.yml#L293

We don't have much test coverage running on Windows.

Should be quick to run on the GitHub CI

refs apache/sedona#2753
@github-actions github-actions bot added github_actions Pull requests that update GitHub Actions code yaml labels Mar 17, 2026
@lprimak
Copy link
Contributor

lprimak commented Mar 18, 2026

Windows tests are already included in the matrix tests.
This is unnecessary

@lprimak lprimak closed this Mar 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

github_actions Pull requests that update GitHub Actions code yaml

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants