Request: set HOMEDRIVE and HOMEPATH environment variables by default

tony's Avatar

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

    Feodor Fitsner's Avatar

    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.

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    Thanks for clarification!

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

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

    Feodor Fitsner's Avatar

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

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

    tony's Avatar

    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)

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

    Feodor Fitsner's Avatar

    Sure, will take a look.

    - Feodor

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

    tony's Avatar

    This is now live and working, thanks!

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

    Feodor Fitsner's Avatar

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

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    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?

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    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 ...".

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

    Feodor Fitsner's Avatar

    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? ;)

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

    Feodor Fitsner's Avatar

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

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    OK, nice.

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    OK, makes sense.

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

    Feodor Fitsner's Avatar

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

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

    tony's Avatar

    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.

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

    Feodor Fitsner's Avatar

    Indeed, I see now. Thanks!

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

    Feodor Fitsner's Avatar

    Fixed, will be deployed shortly.

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

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac