Conda-forge.github.io: noarch recipes are built on all 3 platforms in Pull Requests to staged-recipes

[jdblischak]

Why are noarch recipes submitted to staged-recipes built on Travis and AppVeyor? I couldn't find this discussed anywhere, so I wasn't sure if this was deliberate or if it is a problem of finding the time to update the build scripts.

Not only do these builds unnecessarily use CI time, but they can also fail. Currently any noarch R recipe submitted to conda-forge fails on AppVeyor. This is because we remove a Windows-specific selector to pass the linter checks.

This is happening to all recent noarch R recipes, but here is the PR where I discovered this: https://github.com/conda-forge/staged-recipes/pull/7128

[CJ-Wright]

I don't know if we currently have a good mechanism to stop noarch recipes from being built on all the platforms. Maybe we could have a fast fail clause in the CI for noarch recipes, though.

[jdblischak]

How about checking for the presence of noarch in meta.yaml and removing the recipe directory if it does? Similar to how recipes that are already merged into master are removed:

https://github.com/conda-forge/staged-recipes/blob/fbea79267840338092e2eb2e94bf28ead67328c4/.appveyor.yml#L25

[CJ-Wright]

Any interest in putting in a PR to that effect?

[jdblischak]

Any interest in putting in a PR to that effect?

Of course. Wanted to make sure it was a reasonable option before I attempted it.

[isuruf]

This was intentional to check that other platforms worked with the same recipe. I think we should update the linter. Removing selector lines on windows creates a broken recipe and a person working on windows can't build that package.

[jdblischak]

@isuruf I'd also be fine with that solution. If someone updates the linter, I'll update the R helper script to add back {{posix}}zip to the noarch R recipes.

[jdblischak]

I think we should update the linter.

@isuruf Would you like me to work on the linter update? Both new recipes and PRs to existing R feedstocks are removing {{posix}}zip from the recipe because of the linter.

My plan would be to edit the linter here. Should I remove the entire thing or try to make an exception for R recipes?

[CJ-Wright]

Do we need to be specific that selectors can exist on runtime deps? (Can they exist on runtime deps?)

[jdblischak]

I'm going to give it a try. Runtime deps definitely shouldn't have selectors. Build/host deps are more complicated since they can export runtime deps. I assume that {{posix}}zip doesn't export any runtime requirements (no idea how I would check that though), so this should be safe for the R recipes. Unclear how other potentially more complicated recipes will behave, but presumably any noarch recipe shouldn't be that complicated in the first place.

[CJ-Wright]

@isuruf I'm confused by "check that other platforms worked with the same recipe". What do you mean exactly? I don't know if this is a valid check for noarch packages. Some noarch packages have arched deps (some of which don't exist for that arch) so I don't know if the package will build on other archs.

[jakirkham]

Admittedly I’m not terribly worried about the decision made here. However historically we have only required that the noarch packages build on Linux as this is how we handle them in the feedstocks.

As to how one builds the packages on their platform, there are two strands of thought to consider. First we’ve generally not put too much effort into supporting users, who want to build the package outside of conda-forge, which this seems to fall under. Second noarch packages can be built using the same Docker image and build scripts locally to build on any platform. So this doesn’t really seem like an issue IMHO and am a little worried we are (slightly) diverting people’s efforts without a clear reason.

With staged-recipes CI checks, nothing intentional has been done here. This is really just the typical story of a task that has not moved to high priority and is probably not too difficult. We have dealt with this historically by either ignoring the CIs that are irrelevant or adding [ci skip] to commit messages, which only CircleCI ignores (though this disables the linter). Agree with others that better solutions are welcome here.

[jdblischak]

We have dealt with this historically by either ignoring the CIs that are irrelevant or adding [ci skip] to commit messages, which only CircleCI ignores (though this disables the linter).

I agree that there are easier solutions for those that are privy to this issue with the noarch recipes. My hope was to support conda-forge contributors that submit a valid R recipe, only to be confused by either a failed lint or a failed build.

Agree with others that better solutions are welcome here.

Does anyone have any suggestions?

[CJ-Wright]

As a counter point to https://github.com/conda-forge/conda-forge.github.io/issues/683#issuecomment-446368514 I think that checking the build on all platforms only on staged-recipes might send the wrong message. Changes to the feedstock might prevent the package from working on all platforms, which is not something we check. If we want to check that noarch packages work on all platforms we should do this on feedstocks and staged-recipes to maintain parity.

[jdblischak]

Resolution for R noarch recipes: The linter will ignore selectors in build requirements once a new version of conda-smithy is released (https://github.com/conda-forge/conda-smithy/pull/966). This will allow R noarch recipes to build successfully on Windows, thus easing the staged-recipes review process. The corresponding update to the R recipe helper is also in process (https://github.com/bgruening/conda_r_skeleton_helper/pull/37).

Still unresolved: Should noarch recipes be built for staged-recipes PRs? I had started a PR to do this (https://github.com/conda-forge/staged-recipes/pull/7239), but it would first require 1) consensus to make this change, and 2) someone knowledgeable of PowerShell to fix my initial prototype.