Repository: sagiegurari/cargo-make (Rust)

Issue:
Workspace children do not get executed in order defined in `Cargo.toml` members
### Describe The Bug
The expected behaviour is that the order of execution for a workspace follows the order of the `members` array in `Cargo.toml`. In version v0.36.6 this is broken and appears to follow alphabetical order instead, v0.35.x works without issue

### To Reproduce

1. Have a workspace project with multiple members using cargo-make
2. Execute flow with v0.35 and observe execution order following `members`
3. Execute flow with v0.36 and observe execution order not following `members`

### Code Sample

I was running into this issue on this repo: https://github.com/WootingKb/wooting-analog-sdk I just made the change in the CI to use v0.35 to fix my testing flow. Running `cargo make test-flow` with v0.35 runs and completes successfully, but with `v0.36.6` it fails due to it executing tests on the `wooting-analog-sdk` member before running `wooting-analog-test-plugin` which is a dependency for the `wooting-analog-sdk` tests.



Discussion:
@simon-wh thanks for reporting this.
dependencies are an issue to resolve and its not always possible to define same order.
however, question, if one member is dependend on the other, it should be stated in its cargo.toml so building it would use the current dependency in your filesystem.
or are we talking about some other issue?
Not sure if we're on the same page, I'm talking specifically about the order of execution of workspace members as defined here: 

https://github.com/sagiegurari/cargo-make#workspace-support

> The order of the members is defined by the member attribute in the workspace Cargo.toml.

My members list is:
```
members = [
    "wooting-analog-common",
    "wooting-analog-wrapper",
    "wooting-analog-plugin-dev",
    "wooting-analog-test-plugin",
    "wooting-analog-virtual-control",
    "wooting-analog-sdk-updater",
    "wooting-analog-plugin",
    "wooting-analog-sdk"
]
```

With v0.35 I observe this behaviour (roughly outlining for simplicity): 
```
> cargo make test-flow
wooting-analog-common -> test-flow
wooting-analog-wrapper -> test-flow
...
wooting-analog-test-plugin -> test-flow
...
wooting-analog-sdk -> test-flow
```
so it follows the `members` order exactly.

but with v0.36 when I run the same thing I get:
```
> cargo make test-flow
wooting-analog-common -> test-flow
wooting-analog-plugin -> test-flow
wooting-analog-plugin-dev -> test-flow
wooting-analog-sdk -> test-flow
TEST FAILURE
```
The tests for analog-sdk fail as the `pre-test` task on `wooting-analog-test-plugin` needs to be executed before to prep the necessary files, which usually happens earlier when the order is respected, but with v0.36 that doesn't happen because it runs `wooting-analog-sdk` before it
@simon-wh ya i get it. 
1. i think there were multiple changes and bug fixes in member dependencies that caused this. maybe if you want to investigate and submit a PR, that would be great.
2. in general, maybe worth to see what pre-test does and move it to a place where all members that depend on it can call it. for example you can put it in some common makefile.toml and call it in every member that has a depedency on it
extending common makefile: https://github.com/sagiegurari/cargo-make#usage-workspace-extending-external-makefile
this would actually enable you to run the flow for only one member instead of entire workspace each time
I can confirm that this issue was introduced in v0.36.4 - this version breaks compatibility with the behavior of v0.36.3 and below. I tested each release from v0.36.3 to v0.36.7 and found that contrary to the doc statement "The order of the members is defined by the member attribute in the workspace Cargo.toml." the members of a workspace project are now built in alphabetical order.
thanks for the investigation. 
@vitalytarasov @simon-wh i guess based on your investigations, the issue might be related to this commit:

https://github.com/sagiegurari/cargo-make/commit/6dc8d8586455fbc695ef373309e9d6c3389e3763

would you like to maybe do a deeper dive and maybe provide a PR to keep the solution this commit solves + keep the order?
Hi!

I've ran into same problem (see [1] for my use-case). `git bisect` points to fe5ca3aba1050d0bce39663e0bd270d2a7d83049, that added `members.sort()` call which does not follow the official doc.

I've proposed a fix: https://github.com/sagiegurari/cargo-make/pull/897, so, please take a look if you have time :)


[1] https://stackoverflow.com/questions/76697518/order-of-workspaces-in-cargo-make
confirmed resolved, thank you @pskrgag



Patch:
diff --git a/src/lib/environment/crateinfo.rs b/src/lib/environment/crateinfo.rs
index 21be2c3a..c7b60c04 100755
--- a/src/lib/environment/crateinfo.rs
+++ b/src/lib/environment/crateinfo.rs
@@ -197,7 +197,6 @@ fn add_members(crate_info: &mut CrateInfo, new_members: Vec<String>) {
 fn dedup_members(crate_info: &mut CrateInfo) {
     if let Some(ref mut workspace) = crate_info.workspace {
         if let Some(ref mut members) = workspace.members {
-            members.sort();
             members.dedup();
         }
     }


Test patch:
diff --git a/src/lib/environment/crateinfo_test.rs b/src/lib/environment/crateinfo_test.rs
index 48c49baa..fcdc37da 100755
--- a/src/lib/environment/crateinfo_test.rs
+++ b/src/lib/environment/crateinfo_test.rs
@@ -49,6 +49,24 @@ fn add_members_workspace_new_members_with_data() {
     assert_eq!(workspace.members.unwrap().len(), 2);
 }
 
+#[test]
+fn add_members_workspace_non_alpha_ordered() {
+    let mut crate_info = CrateInfo::new();
+
+    crate_info.workspace = Some(Workspace::new());
+    add_members(
+        &mut crate_info,
+        vec!["test2".to_string(), "test1".to_string()],
+    );
+
+    load_workspace_members(&mut crate_info);
+
+    let members = crate_info.workspace.unwrap().members.unwrap();
+    assert_eq!(members.len(), 2);
+    assert_eq!(members[0], "test2".to_owned());
+    assert_eq!(members[1], "test1".to_owned());
+}
+
 #[test]
 fn add_members_workspace_empty_members_with_data() {
     let mut crate_info = CrateInfo::new();