Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tools: fix Cygwin CI build #29013

Merged
merged 2 commits into from
Jan 7, 2025
Merged

Conversation

tpwrules
Copy link
Contributor

@tpwrules tpwrules commented Jan 5, 2025

There are currently issues where the non-.exe-suffixed files can't be copied into the artifacts folder; cp claims "File exists". Previously this worked but the suffix was added by Cygwin so all files in artifacts had a .exe suffix anyway.

This is evidently intended, though non-intuitive, behavior: https://sourceware.org/legacy-ml/cygwin/2009-08/msg00293.html

On Cygwin, you should avoid having a file "foo" and a file "foo.exe" in the same directory at all cost to avoid puzzeling POSIX borderline behaviour like this. What you do is essentially in the "not supported" class of problems.

[...] Cygwin does not check for a file "foo", if the name of the file is explicitely given as "foo.exe".

Apparently something similar was addressed in PR #20926; the current code installs files with both suffixes, but that fix contradicts the info above and now has broken.

This PR changes the code to only install .exe-suffixed files, as opposed to only non-.exe-suffixed files, which was the behavior before that PR. The set of installed files should not actually change.

There are currently issues where the non-.exe-suffixed files can't be
copied into the `artifacts` folder; `cp` claims "File exists".
Previously this worked but the suffix was added by Cygwin so all files
in `artifacts` had a `.exe` suffix anyway.

This is evidently intended, though non-intuitive, behavior:
https://sourceware.org/legacy-ml/cygwin/2009-08/msg00293.html

> On Cygwin, you should avoid having a file "foo" and a file "foo.exe"
> in the same directory at all cost to avoid puzzeling POSIX borderline
> behaviour like this.  What you do is essentially in the "not
> supported" class of problems.

> [...] Cygwin does not check for a file "foo", if the name of the file
> is explicitely given as "foo.exe".

Apparently something similar was addressed in PR ArduPilot#20926; the current
code installs files with both suffixes, but that fix contradicts the
info above and now has broken.

This PR changes the code to only install .exe-suffixed files, as opposed
to only non-.exe-suffixed files, which was the behavior before that PR.
Copy link
Collaborator

@robertlong13 robertlong13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, good find on that mailing list.

Using the master branch exposed us to transient breakage as the action
was developed.
@tpwrules
Copy link
Contributor Author

tpwrules commented Jan 6, 2025

Looks like the root cause for the change in observed behavior was us using the master branch of the Cygwin install action, which had a bug for a little while that caused it to install the testing versions of packages by default. It's now fixed in the master branch so CI will work again as is, but I've added another commit to use the latest released version (which includes the fix for that bug) instead. It's also probably best to fix our misuse of the .exe extension now.

@tridge
Copy link
Contributor

tridge commented Jan 7, 2025

cygwin CI populates this: https://firmware.ardupilot.org/Tools/MissionPlanner/sitl/

@tridge tridge merged commit f3e610c into ArduPilot:master Jan 7, 2025
99 checks passed
@tpwrules tpwrules deleted the pr/fix-cygwin-ci branch January 7, 2025 02:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Pending
Development

Successfully merging this pull request may close these issues.

5 participants