Skip to content

Conversation

directhex
Copy link
Contributor

Still build functional etc tests, as a sanity check, but gate the libraries test builds behind a big ol' if statement

This PR submission should do a test build.

Additionally, keep the functional tests around - their building (or not building) is as much what we're testing as whether they run fine or not on Helix.

…sts to Helix

Still build functional etc tests, as a sanity check, but gate the libraries
test builds behind a big ol' if statement
@ghost
Copy link

ghost commented Sep 1, 2021

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

Still build functional etc tests, as a sanity check, but gate the libraries test builds behind a big ol' if statement

This PR submission should do a test build.

Additionally, keep the functional tests around - their building (or not building) is as much what we're testing as whether they run fine or not on Helix.

Author: directhex
Assignees: -
Labels:

area-Infrastructure-libraries

Milestone: -

<ProjectReference Include="$(MSBuildThisFileDirectory)*\tests\**\*.Tests.csproj"
Exclude="@(ProjectExclusions)"
Condition="'$(TestAssemblies)' == 'true'" />
Condition="'$(TestAssemblies)' == 'true' and
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a very long complicated condition, couldn't you choose to skip the entire build step like the "Send to Helix" part does? (or do you need the non-test-project build to run here?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building the functional tests is important on some platforms, as a way to integration test multiple things like the AOT tasks, LDAP tasks, linker, etc.

I could make the conditional even more complex by restricting it to only specific platforms...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way to express it might be with a property, like:

<PropertyGroup>
  <IncludeLibraryTests Condition="'$(TestAssemblies)' != 'true'">false</IncludeLibraryTests>
  <IncludeLibraryTests Condition="'$(IncludeLibraryTests)' == '' and '$(ContinuousIntegrationBuild)' != 'true'">true</IncludeLibraryTests>
  <IncludeLibraryTests Condition="'$(IncludeLibraryTests)' == '' and '$(RuntimeFlavor)' != 'Mono'">true</IncludeLibraryTests>

  <IncludeLibraryTests Condition="'$(IncludeLibraryTests)' == '' and
      '$(RuntimeFlavor)' == 'Mono' and
          ('$(librariesContainsChange)' == 'true' or
           '$(monoContainsChange)' == 'true' or
           '$(isFullMatrix)' == 'true')">true</IncludeLibraryTests>
  <IncludeLibraryTests Condition="'$(IncludeLibraryTests)' == ''">false</IncludeLibraryTests>
</PropertyGroup>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can achieve that on the yaml as well? Either way I'm fine, but I do agree this is a very hard to read condition.

@directhex directhex closed this Feb 14, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Mar 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants