Open muellerto opened 7 years ago
Thank you for the detailed report! I think the first point is related to #52, because I implemented a fix for the sorting issue there too. If I understood your second issue correctly this should also be fixed. You can grab the fix under this link: https://ci.appveyor.com/project/StefanKert/buildvision/build/2.1.1.150
Let me know if this fixes your issue! Thanks again for the great description.
Installed this. (I'm not sure if this really runs here. I just clicked on the vsix-file and then came an installer who did something ... Then I restarted VS.)
In my case the behavior is unchanged.
The sort order during or after a solution build is not right. It sorts by something, the resulting order of the projects seems to be determined, but I can't figure out by what. There seems to be somehow a constant hidden order which is always used except the user sorts manually. If the user sorts manually the list is reordered for the moment but the hidden order remains probably untouched. Then, whenever the next build operation is started, the hidden order comes again into the list.
The second issue is building a single project in the solution. This should never cause a resort at all because it's not a solution operation, but it does, even after the fix. You see this easily when you manually resort the list by clicking on # and then start a single project build - the first thing happening is again a resort (into the hidden order).
Can you double check which version you´ve installed? You can do this by going to your BuildVision settings. There should be a section that looks like this:
Please verify that you´ve installed 2.1.1.150
In this build the sorting during the build is working properly for me. There is just an issue with the UI that the # is actually not showing any state of the sort order. So if the order looks wrong, just click on the # again. I will try to fix this UI issue, but the sorting should work properly.
I think the second issue has as well to do with the UI issue, but can you please verify, that this is working if you click on the # button again? Will let you know if I fixed the UI issue! Thanks
My version is:
During a solution build it looks like this:
All the projects have their place in the list. One by one they get a number but the positions never change. The order is constant from the beginning of the build until the end. But there's a ^ in the # column.
What you need to reproduce this is a large solution with build dependencies between the projects, I have dependencies up to 4 levels (A depends on B, B on C, C on D, D on E). And parallel build processes are also helpful to get differences between several builds.
(Damned, I pressed Close and Commit)
Wow ok! The fill projects at beginning was the missing link for me. I was able to reproduce this. I will try to fix this and get back to you if I got a fix! Thanks for reporting this and taking the time to bring up so many details.
Finally I managed to fix this issue. Can you double check if it is working for you now? You can grab the build by going to https://ci.appveyor.com/project/StefanKert/buildvision/build/2.1.1.154
Thanks :)!
Hey, it looks indeed much better now!
In both cases (ascending and descending sort) the user has a good overview of what's happening and in which order. OK, in descending sort order the list is still changing while a build is running but this is orderly done, the user can recognize what's going on.
Thanks a lot for this!
Hey there! Thanks for the reply. Glad that it worked out. Can you send me a screenshot of the issues with descending sort? Maybe I can fix this issue too. Thank you!
Look at this picture: In descending sort order the uncompiled projects are initially at the bottom. This is the same as with ascending sort order. During the compilation they walk one by one to the top of the list. So the list changes during a build. This is different from ascending sort where the list remains constant all the time.
After some minutes the list looks like this: It's usable this way, and not at all bad.
But the question is: why is descending sort order also optically not just the direct opposite from ascending sort order? Why it's different? If we have the imagination that a build just runs over the projects as we see them in the list and in ascending sort order a build runs indeed top down - why are in descending sort order uncompiled projects not always at the top of the list and the build runs just bottom up? This is what a user would expect.
If you see the user wants a list sorted by build order you must
Don't allow any changes during the build, except the user himself changes the sort criteria.
Note: using other sort columns (by build duration, start time, end time, state ...) changes in the list are allowed and needed during a build, if you sort by build order they are not.
sorry for the delay in my reply! Thanks again for the detailed description of the issue. I will look into this and see if I can come up with a fix for this asap to get it into the next release wich is planned for this week.
I´ve taken a look at this and let me just say some things to this case:
The sort order indeed is as you mentioned. If descending all projects are correctly sorted, but the projects with no order set are at the bottom.
If you see the user wants a list sorted by build order you must
- determine the build order,
- fill the list (ascending or descending sorted) and
- let it be constant under all circumstances.
Don't allow any changes during the build, except the user himself changes the sort criteria.
So the problem we are facing is, that the buildorder is completly defined during the build and it is not (or not without a big amount of effort) possible to calculate this order before the begin of the build.
What I would like to suggest is, that we do the following:
Please let me know what you think about this!
thanks
Seems to be the best what is to achieve. This would make ascending and descending sort look indeed the same, only reverted, and this is what the user expects.
I'm not familiar with this API. I always thought the build order is known and requestable before (!) a build begins. The project dependencies are known, the user can set them. So I thought you can always fill the list and let it be. If the build order develops itself during the build it's a completely other situation.
Thanks a lot for your work.
I would like to have the projects in the BuildVision window by build order so that a solution build runs just from top to bottom on the screen.
The problem is that this sort order is not right in many cases. The following picture shows the result of a solution build initially sorted by build order:
If I now run the same solution build again the build order changes a bit (see the numbers, this comes by parallel build processes) but the order of the projects in the list remains the same:
If I now resort manually by clicking on the # column header several times until I find it's right now and then start again an entire solution build it does initially a resort of the entire list I don't know by what and the result is again wrong:
After all I must report sorting by build order is never right except I do it manually directly after a solution build.
BuildVision should