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

FileCollection iteration order is not stable accross different operating systems #29321

Closed
martinbonnin opened this issue May 27, 2024 · 1 comment
Labels
a:bug closed:not-fixed Indicates the issue was not fixed and is not planned to be in:configuration-model lazy api, domain object container

Comments

@martinbonnin
Copy link
Contributor

martinbonnin commented May 27, 2024

Current Behavior

Iterating a FileCollection yields different results depending the operating system the build is run on.

Expected Behavior

Iterating a FileCollection should be stable, no matter what the operating system is.

This is especially important for @Classpath inputs where the order matters.

Context (optional)

Gradle community slack thread: https://www.linen.dev/s/gradle-community/t/18849228/is-the-iteration-order-of-a-filecollection-predictable#9f987382-a54f-493a-89c5-3474e22a97dd

Steps to Reproduce

I put a reproducer here. The gist of it is:

val sourceDirectorySet = objects.sourceDirectorySet("graphql", "graphql").apply {
    srcDirs("graphql")
    include("**/*.graphql")
}

val files = mutableListOf<String>()
sourceDirectorySet.asFileTree.visit {
    files.add(this.path)
}

check(
    listOf(/* ... */) == files
) {
    "The order is not the expected one"
}

The GitHub action fail on linux while it succeeds on MacOS (action run)

Screenshot 2024-05-27 at 17 05 13

Gradle version

8.7

Build scan URL (optional)

No response

Your Environment (optional)

No response

@martinbonnin
Copy link
Contributor Author

Looks like this is working as designed, cf https://docs.gradle.org/current/userguide/declaring_dependencies.html#ex-declaring-multiple-file-dependencies:

The order of the files in a FileTree is not stable, even on a single computer. It means that dependency configuration seeded with such a construct may produce a resolution result which has a different ordering, possibly impacting the cacheability of tasks using the result as an input.

It'd be nice to have different input types/annotations to convey order vs unordered but in all cases, my question is answered, I'll close this issue.

@mlopatkin mlopatkin added the closed:not-fixed Indicates the issue was not fixed and is not planned to be label May 28, 2024
@mlopatkin mlopatkin closed this as not planned Won't fix, can't repro, duplicate, stale May 28, 2024
@mlopatkin mlopatkin added in:configuration-model lazy api, domain object container and removed to-triage labels May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:bug closed:not-fixed Indicates the issue was not fixed and is not planned to be in:configuration-model lazy api, domain object container
Projects
None yet
Development

No branches or pull requests

2 participants