You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll have to check the git commands again, though it is hard to get a list of changed files from the CI as the git history isn't pulled by default.
If we could, we could try and detect the modified experiments as part of a PR and have a separate job which uses that info to build/validate those experiments only (alongside the full build).
This could be useful as our all-up build grows to give quick status back on the immediate change. We could also use it to push these interim changes of packages to the PR specific feed to bring back that functionality we have in our main repo currently...
Thoughts?
The text was updated successfully, but these errors were encountered:
Yes, it'd be nice to only build and run the tests against the experiment that has changed and not against all of them.
Figuring out how to do it might be a challenge but it's definitely something that would be useful to have.
Yes, it'd be nice to only build and run the tests against the experiment that has changed and not against all of them. Figuring out how to do it might be a challenge but it's definitely something that would be useful to have.
I would not expect running the tests to be a big factor in the overall time taken. It's the release builds that take time.
In addition to detecting changes in individual experiments to see what to rebuild, it's also going to be necessary to rebuild everything if any shared component is changed. This makes the logic for detecting what to rebuild and when more complicated :(
I know how to use MSBuild to detect all the experiments to build (& pack) without specifying names (& paths) explicitly but not how to then combine that with using git diff to detect what's changed. I expect that might need some specific scripting.
I had played around with this a bit with the XAML Styler changes, but realized it's hard to test locally vs. the CI as the CI usually doesn't checkout the full repo/history.
Anyway, will just leave this here for future tracking for now.
Setting up #65 and #33 gave me a thought.
I'll have to check the git commands again, though it is hard to get a list of changed files from the CI as the git history isn't pulled by default.
If we could, we could try and detect the modified experiments as part of a PR and have a separate job which uses that info to build/validate those experiments only (alongside the full build).
This could be useful as our all-up build grows to give quick status back on the immediate change. We could also use it to push these interim changes of packages to the PR specific feed to bring back that functionality we have in our main repo currently...
Thoughts?
The text was updated successfully, but these errors were encountered: