CircleCI not uploading binaries

[jakirkham]

Not sure why, but CircleCI is not uploading binaries here. It builds all the way through and even passes its tests. However, it does not try to upload at all.

cc @pelson

[jakirkham]

Tried bumping the build number, but no difference. The build seems to be going fine. Not sure why the upload step never happens. Is it confused because there are 2 digits in the major number? Seems like a weird thing, but it is all I can think of here.

[pelson]

CircleCI token is defined in their configuration, rather than as a secret in the yaml itself. I double checked the erlang feedstock (https://circleci.com/gh/conda-forge/erlang-feedstock/edit#env-vars) and the token looks fine.

The stdout from the build doesn't appear to call the upload script, although it looks to be defined correctly.

[pelson]

I'm not entirely sure what is wrong with this one - the build log is quite long, but I can't imagine Circle clip the build when the log length is exceeded.

Hmmm

[jakirkham]

Yeah, it's very strange.

This is sort of a lazy solution, but could we delete and try to create the feedstock again? It could have the same result, but then again maybe not. Nothing else seems to have had this issue.

[jakirkham]

@scopatz, @pelson and I chatted about this briefly today and we are still very puzzled by this. Everything appears setup correctly on the CircleCI end. Everything else we looked at seems ok. There aren't any error messages suggesting the upload failed for some reason. We will keep this in mind. However, we likely won't have time to get to this again until Wednesday when @pelson is back.

[scopatz]

Ok, no worries on the timing. Thanks for looking into it.

[jakirkham]

Going to try re-adding it as a feedstock. See this PR ( conda-forge/staged-recipes#566 ). In practice, this doesn't really change anything here (e.g. the recipe doesn't change). However, it will go back through the configuration process and so maybe it will fix something that got screwy. 💫 Then again it could do nothing. It is just something easy to try.

[jakirkham]

Weird. That made absolutely no difference. @pelson, any other ideas we could try?

[scopatz]

Ugg very strange.

[pelson]

Just looked at this in a bit more detail and I imagine it is related to the output being too long (which is weird). It looks like if there is too much output, the next step in the build doesn't get run. I'm experimenting in a no_exit branch on this feedstock (https://github.com/conda-forge/erlang-feedstock/tree/no_exit).

[pelson]

This is sort of a lazy solution, but could we delete and try to create the feedstock again? It could have the same result, but then again maybe not. Nothing else seems to have had this issue.

That kind of solution only works for Windows 😜

Looks like it wasn't anything to do with the log length either - it still stops immediately after the build+test (https://circleci.com/gh/conda-forge/erlang-feedstock/12). I guess it could be a sigterm or something from the erlang test. Have you tried removing it?

[jakirkham]

That kind of solution only works for Windows 😜

😆 Hardly.

Looks like it wasn't anything to do with the log length either - it still stops immediately after the build+test (https://circleci.com/gh/conda-forge/erlang-feedstock/12). I guess it could be a sigterm or something from the erlang test. Have you tried removing it?

I mean it just checks the version. Besides, if there was such a signal, why wouldn't that just crash conda-build?

[pelson]

@jakirkham - did you ever try running this on a local docker?

[jakirkham]

Yep. There are no weird exit codes that I found. I even tried doing this ( #7 ), which seems to make no difference AFAICT.

[jakirkham]

So, I think the last time we were looking at something related to this we were considering taking out the tests. Should we try this?

[pelson]

Didn't we already test this?

[jakirkham]

Nope. We noted we should test it after it worked somewhere else. Should be easy enough to try.

[pelson]

xref: conda-forge/nco-feedstock#20

[jakirkham]

This should be fixed by PR ( #15 ).

[jakirkham]

Had a bit of a false start, but it seems we have fixed this issue. Linux builds are now available. As it required disabling the tests, went ahead and opened issue ( #16 ) to remind us to try and get them working again.