Home → Suggestions →

Request: set HOMEDRIVE and HOMEPATH environment variables by default

• Edit

tony

05 Mar, 2014 12:02 PM

First of all, AppVeyor's new CI service is fantastic. A Travis-like CI system for Windows has been sorely needed, and the only other trial of this kind of thing by any other company that I know of has unfortunately ended. I hope AppVeyor sticks with it. The 10-minute default time limit is rather limiting since just installing my dependencies takes almost half that, but my limit appears to have increased to 30 minutes at some point so thanks for that! Edit: apparently this was changed for everyone http://help.appveyor.com/discussions/questions/195-large-projects#c..., I just happened to notice immediately when the limit went up :)

My request is due to the software that I'm most interested in building with AppVeyor, Julia (www.julialang.org) and packages for it. Julia's package manager uses the value of HOME, or as a fallback HOMEDRIVE concatenated with HOMEPATH, as the default location for installing packages. I'd like to encourage Julia package maintainers to use AppVeyor CI to catch errors on Windows faster, since most of them already use Travis and the appveyor.yml can be adapted with relatively minor changes from their existing .travis.yml. It would be nice if it was not necessary to add the extra lines for setting HOMEDRIVE and HOMEPATH to every single package's appveyor.yml.

1. Support Staff 1 Posted by Feodor Fitsner on 05 Mar, 2014 05:12 PM

   

   Hi Tony,

   Thanks for the kind words! I'm glad you like the service.

   Sure, we will add HOME, HOMEDRIVE and HOMEPATH variables to default environment.

   • Edit

2. 2 Posted by tony on 05 Mar, 2014 08:03 PM

   

   Great, thanks! Look forward to being able to remove some clutter from my appveyor.yml.

   To clarify, I think it’s better if HOME remains unset, only setting HOMEDRIVE and HOMEPATH by default. I believe that’s the most common setup on Windows systems. The reason Julia’s package manager looks in HOME first is for *nix OS’es, so it’s actually good to test that the fallback is working in a way that will be representative of user systems.

   • Edit

3. Support Staff 3 Posted by Feodor Fitsner on 05 Mar, 2014 09:46 PM

   

   Thanks for clarification!

   HOME variable is anyway set when cloning private repositories - it's needed for SSH to work.

   • Edit

4. Support Staff 4 Posted by Feodor Fitsner on 07 Mar, 2014 05:33 PM

   

   Apparently, HOMEDRIVE and HOMEPATH are set by default on Windows Server :)

   • Edit

5. 5 Posted by tony on 08 Mar, 2014 10:12 AM

   

   Really? I'm still not seeing them defined: https://ci-beta.appveyor.com/project/tkelman/json-jl/build/1.0.23
   (ignore the warning about CPU_CORES, that's happening inside Julia)

   • Edit

6. Support Staff 6 Posted by Feodor Fitsner on 08 Mar, 2014 04:19 PM

   

   Sure, will take a look.

   - Feodor

   • Edit

7. 7 Posted by tony on 11 Mar, 2014 12:32 AM

   

   This is now live and working, thanks!

   • Edit

8. Support Staff 8 Posted by Feodor Fitsner on 11 Mar, 2014 12:36 AM

   

   Wow, it was deployed 5 minutes ago and I was going to update you :)

   • Edit

9. 9 Posted by tony on 11 Mar, 2014 12:58 AM

   

   Cool. I was doing some other work and noticed something had changed between builds - git clone gives progress messages now which it didn't do before, and if doesn't seem to work in cmd script lines any more?
   'if' is not recognized as an internal or external command, operable program or batch file.

   • Edit

10. Support Staff 10 Posted by Feodor Fitsner on 11 Mar, 2014 01:05 AM

    

    It was changed how AppVeyor calls batch commands - now every command runs in external process, not in PS runspace (StdErr is redirected to StdOur, that's why git clone shows progress - I was doing that to make node.js working nicely in AppVeyor environment).

    However, the way script blocks are interpreted was not changed. As before "cmd" script is broken into lines and each line is run as separate command; "ps" blocks run entirely.

    If you need control-flow logic use PowerShell.

    Can you paste a script that was working before update?

    • Edit

11. 11 Posted by tony on 11 Mar, 2014 01:12 AM

    

    That makes sense, I was already redirecting stderr to stdout myself so fewer normal messages showed up in red as NativeCommandError from PowerShell.

    Relevant pieces of what I was doing:
    

    environment:
      matrix:
      - XC_HOST: "i686-w64-mingw32"
      - XC_HOST: "x86_64-w64-mingw32"
    install:
      - "cinst cyg-get > cyg-get.log"
      - set PATH=%PATH%;C:\cygwin
      - "if %XC_HOST% == x86_64-w64-mingw32 (cyg-get mingw64-x86_64-gcc-g++) else (cyg-get mingw64-i686-gcc-g++)"
    

    I'll work out how to do the same thing in PowerShell, it was just a bit more concise this way.

    • Edit

12. Support Staff 12 Posted by Feodor Fitsner on 11 Mar, 2014 01:24 AM

    

    Oh, I see.

    In the latest update command is pre-pended with "call " - this is to make guys like npm, gem and apparently child batch scripts do not aborting the batch (more info here: http://stackoverflow.com/questions/9773486/batch-file-closes-before...), so your command becomes "call if ...".

    • Edit

13. Support Staff 13 Posted by Feodor Fitsner on 11 Mar, 2014 01:28 AM

    

    UPDATE: Working on recent support requests showed that for people is more natural to write in appveyor.yml gem update --system or myscript.cmd versus call gem update --system or call myscript.cmd.

    Maybe we can do kinda hard-code for 'if' batch clause? ;)

    • Edit

14. Support Staff 14 Posted by Feodor Fitsner on 11 Mar, 2014 01:39 AM

    

    OK, added exceptions for IF and FOR. Will deploy shortly.

    • Edit

15. 15 Posted by tony on 11 Mar, 2014 01:44 AM

    

    It was pretty trivial to use powershell instead:
    ps: if ($env:XC_HOST -eq "x86_64-w64-mingw32") {cyg-get mingw64-x86_64-gcc-g++} else {cyg-get mingw64-i686-gcc-g++}

    I was using some output redirection to a file because cyg-get is very noisy, I'm figuring out if I can still do that easily.

    Yep, worked fine as
    ps: 'if ($env:XC_HOST -eq "x86_64-w64-mingw32") {cyg-get mingw64-x86_64-gcc-g++ >> cyg-get.log} else {cyg-get mingw64-i686-gcc-g++ >> cyg-get.log}' Extra quotes just for good measure since >> can occasionally confuse the YAML parsing.

    • Edit

16. Support Staff 16 Posted by Feodor Fitsner on 11 Mar, 2014 01:45 AM

    

    OK, nice.

    • Edit

17. 17 Posted by tony on 11 Mar, 2014 01:48 AM

    

    While you're tweaking things, -q on the initial clone will be nice to make logs shorter now that stderr messages are showing up there.

    • Edit

18. Support Staff 18 Posted by Feodor Fitsner on 11 Mar, 2014 01:57 AM

    

    OK, makes sense.

    • Edit

19. Support Staff 19 Posted by Feodor Fitsner on 11 Mar, 2014 05:21 AM

    

    You mean you see those Checking out files in the log? Can you send an example?

    • Edit

20. 20 Posted by tony on 11 Mar, 2014 05:29 AM

    

    Sure, see https://ci-beta.appveyor.com/project/tkelman/julia/build/1.0.205

    I think it needs to be a relatively large repo to notice.

    • Edit

21. Support Staff 21 Posted by Feodor Fitsner on 11 Mar, 2014 05:32 AM

    

    Indeed, I see now. Thanks!

    • Edit

22. Support Staff 22 Posted by Feodor Fitsner on 11 Mar, 2014 06:10 AM

    

    Fixed, will be deployed shortly.

    • Edit

23. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:37 AM.