Hang on PkgEval

[maleadt]

RemoteHPC.jl hangs when being tested on PkgEval:

        Info Packages marked with ⌅ have new versions available but compatibility constraints restrict them from upgrading. To see why use `status --outdated -m`
[ Info: Creating new Server configuration...
Username: 

################################################################################
# PkgEval teardown
#

Started at 2022-11-08T20:17:34.335

PkgEval terminated after 5400.01s: test duration exceeded the time limit

It seems to prompt for a username, and just sits there for the maximum time allowed consuming 100% CPU. Example log: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_date/2022-11/08/RemoteHPC.primary.log.

[louisponet]

Hi @maleadt,

Super sorry for not seeing this issue earlier, had no idea anyone but me was using this. Is the problem persisting?

Cheers,
Louis

[maleadt]

had no idea anyone but me was using this

Well, you registered the package, which indicates some type of intended public use :-)

The latest test logs now indicate a different error:

ERROR: LoadError: AssertionError: Something went wrong installing RemoteHPC on server, please install manually

So yeah, it is still problematic. I will blacklist the package for now.

[louisponet]

Well yes, but since I only pushed it to my colleagues I wasn't keeping track of issues here :P.

I think this is the same issue as I'm facing with the tests on julia 1.6. I will look into it and let you know.

[louisponet]

Hi @maleadt ,

I think the problem should now be fixed in v0.3.3 . It had to do with eachsplit not existing before julia 1.8.

Cheers

[timholy]

That seems unlikely, as the PkgEval run used julia-1.9. Click on the log in the OP, it seems likely due to

[ Info: Creating new Server configuration...
Username: 

and then it just hangs.

In the meantime, it seems that this package has been blocked from testing in future PkgEval runs. If you fix the issue more thoroughly and want it evaluated against future Julia versions, you might want to contact someone to get it reinstated.

[louisponet]

Hmm, weird because the tests run on julia nightly. I will try with PkgEval locally

[louisponet]

Hi @timholy,

I don't think the issue in the original log was still present in the last run as mentioned by @maleadt. Seen as CI tests here are ran succesfully on julia 1.6 1.8 and nightly, I do think the issues are now fixed. I tried running PkgEval locally but since it's blacklisted I can't seem to actually perform the trials. I couldn't find an option in Package to point it to a certain path.

I hope this means it can be deblacklisted.
Cheers

[maleadt]

I'll remove the blacklist and see if it passes tests again.

[maleadt]

ERROR: LoadError: AssertionError: Something went wrong installing RemoteHPC on server, please install manually
Stacktrace:
  [1] install_RemoteHPC(s::RemoteHPC.Server, julia_exec::String)
    @ RemoteHPC ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:251
  [2] install_RemoteHPC
    @ ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:242 [inlined]
  [3] configure!(s::RemoteHPC.Server; interactive::Bool)
    @ RemoteHPC ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:135
  [4] configure_local(; interactive::Bool)
    @ RemoteHPC ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:151
  [5] RemoteHPC.Server(s::String; overwrite::Bool)
    @ RemoteHPC ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:171
  [6] Server
    @ ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:165 [inlined]
  [7] local_server
    @ ~/.julia/packages/RemoteHPC/HEOKb/src/servers.jl:218 [inlined]
  [8] macro expansion
    @ ~/.julia/packages/RemoteHPC/HEOKb/src/RemoteHPC.jl:50 [inlined]
  [9] top-level scope
    @ ~/.julia/packages/SnoopPrecompile/1XXT1/src/SnoopPrecompile.jl:62
 [10] include
    @ ./Base.jl:456 [inlined]
 [11] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::String)
    @ Base ./loading.jl:1952
 [12] top-level scope
    @ stdin:2
in expression starting at /home/pkgeval/.julia/packages/RemoteHPC/HEOKb/src/RemoteHPC.jl:1

Your package should not attempt to do things like

RemoteHPC.jl/src/servers.jl

Line 250 in cb8d9dd

res = julia_cmd(s, "using Pkg; Pkg.activate(joinpath(Pkg.depots()[1], \"config/RemoteHPC\")); Pkg.add(\"RemoteHPC\");Pkg.build(\"RemoteHPC\")")

, let alone from global scope (during precompilation).

[louisponet]

Is the build step not ran during PkgEval perhaps? Normally the local_server() should exist after the build step. I don't really understand why else the CI works but PkgEval doesn't

[louisponet]

I've been trying to run PkgEval locally, is there a way for me to force test RemoteHPC even though it's blacklisted? I can't seem to find how to do that

[louisponet]

In the log I indeed don't see the build step running. Is that standard behavior?

[maleadt]

I've been trying to run PkgEval locally, is there a way for me to force test RemoteHPC even though it's blacklisted? I can't seem to find how to do that

The blacklist is automatically ignored if you explicitly test a package: https://github.com/JuliaCI/PkgEval.jl/blob/22093d2b79057e8583c32ce5df39df3619cba052/src/evaluate.jl#L992-L993

That said, the build step not running here is curious. Testing locally it does run, and your packages does pass tests; I'll look into whats happening.

That said, I'd strongly recommend against running such commands from top level. It's better to just error("This package hasn't been build, please run Pkg.build").

[louisponet]

Oh that's a very good solution. I understand these type of commands are really not ideal, it's that nothing in the package will work if the local server configuration did not get created.
It is a bit unfortunate that trying to construct Server() with a name that wasn't known before triggers the interactive configuration which is the only time install_RemoteHPC should ever be called anyway. I'm working on changing that behavior in any case, but so far I did not have the time to figure it out completely.

That being said, I will run an explicit check on the existence of a local configuration + report the error you suggest, since for now that is certainly the way to go.

Thanks, and sorry for the headaches...