[question] conan graph build-order fails (exit code 1) with invalid configurations

[lordjaxom]

What is your question?

Suppose I have a recipe that can only be built on Windows. So the validate method raises ConanInvalidConfiguration on other platforms.

Previously, with Conan 2.5.0 I could do a conan graph build-order --order-by=configuration --format=json --requires=myrecipe/1.0, which would exit with code 0 and a node with "binary": "Invalid".

After updating to Conan 2.7.0, I get the same JSON but Conan exits with code 1 and reports

ERROR: There are some error(s) in the graph:
           - myrecipe/1.0:7da5f3af116f87b3327cf622977d27b619cccbc3: Invalid configuration

Is this an intended behaviour change?

We are using build-order in the pipeline of our conan-center-index fork to determine which packages have to be built in which order, in case a commit changes more than one package. Since each package can yield multiple versions, we can't use --reduce, but use build-order-merge later on.

BTW: Is there any documentation how the CI/CD stack of conan-center-index works? I am getting the impression that our approach isn't ideal and I'm sure there a lots of ideas waiting to be discovered :-)

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @lordjaxom

Thanks for your question.

After updating to Conan 2.7.0, I get the same JSON but Conan exits with code 1 and reports

Indeed, this was changed in Conan 2.7, considered a bug not raising an error for a couple of reasons:

• Other equivalent commands to raise an error for exactly the same dependency graph. It doesn't make sense that a conan install fails, but a conan graph build-order happily returns a build-order json for the same graph.
• It didn't make sense to have a graph build-order json that couldn't be used to build things because it is incorrect/invalid, and putting the burden on the users to check every node in the graph to validate if all of them are valid. Basically a build order that contains either invalid or missing cannot be used for build, even the missing ones, because forcing their build will create a different graph that the one that was computed in the graph build-order and that defeats the purpose of the command in the first place.

Please let me know if this clarifies the change. In theory it shouldn't block the recommended build-order (without reduce) + build-order-merge later.

BTW: Is there any documentation how the CI/CD stack of conan-center-index works? I am getting the impression that our approach isn't ideal and I'm sure there a lots of ideas waiting to be discovered :-)

There is little documentation about CI processes, but we are on it, we are writing a whole new tutorial for it, see https://github.com/conan-io/docs/pull/3799. I think this can help a lot, and the plan is to finish and release it soon (a few weeks hopefully)