Windows builds about vscodium HOT 30 CLOSED

@Calinou @wmhilton
I plan on using AppVeyor instead of Travis+Wine, as I have had some success with that in another project. PRs are welcome for an AppVeyor yaml file. I will try to do it in the coming days/weeks if I get some time.

from vscodium.

@gerroon yes! I am trying to figure out why it didn't auto build. Should have them later today.

from vscodium.

It's open in a PR #58. If you want releases now you can check https://github.com/pavanagrawal123/vscodium

from vscodium.

As far as I know, if you have WINE and rcedit installed (to change the application icon and metadata), it should be possible to cross-compile Electron applications without requiring a full C/C++ toolchain.

However, I tried running gulp vscode-win32-x64 on Fedora 28 and while the build succeeds, I only get a gray window when running it on Windows.

I wonder if it would be easier to use AppVeyor instead. This could require the use of a tool like gothub to deploy build artifacts from AppVeyor and Travis CI to GitHub Releases, as Travis CI's built-in deployment tool may not be able to cooperate with other CI systems.

Edit: Deployment of builds using both Travis CI and AppVeyor's built-in deployment systems seems to work fine in trust, so it's probably not an issue.

from vscodium.

@stripedpajamas
Hi! I've been putting a little time into setting this up with appveyor. Today I finally managed to get a build successful (lots of polish/debug to remove), but as I've been developing in the dark, I figure a quick sanity check is in order before I invest more time polishing.
I'm still not completely sure what to do as far as packaging it up for Windows consumption. I'm thinking for the time being we'll provide just a zip file with the output contents, and let users do their own unzipping/install. Microsoft seems to provide the equivalent zip as an option of their set of downloads, though it is the least preferred. Is this in line with what you're thinking?
This will seem to conflict with the OSX logic in check_tags.sh, which appears to only check that the name element of the asset contains "zip". Do you have a preference for how we handle that? The simplest thing I see is to replace "zip" with "darwin"...

from vscodium.

@TimothyDJewell The official Visual Studio Code Windows installers are created using Inno Setup. I remember seeing the .iss file used by Microsoft to create those somewhere, but I can't find it anymore.

I think providing both options (installer + ZIP archive) is the best. Installers are better-suited for beginners (as they make it easy to add VS Code to the PATH), but ZIP archives are more suited for automated installations (e.g. when using Scoop).

from vscodium.

Thanks @Calinou! Looks like it's currently at /build/win32/code.iss. I've never done any of this before, but I'll give it a shot. I agree that matching the VS Code options is best.

from vscodium.

@TimothyDJewell thanks for the work so far. Excited to see a Windows build in the near future.

Duplicating whatever MS has on their download page is definitely the route to go. It looks like they do provide a zip and an exe, the executable being preferable. Since this is all happening in Appveyor, we shouldn't have to worry about the existing build scripts used by Travis at all. Since you are able to control the Windows output file names, we can make an Appveyor equivalent of the check_tags.sh script check for those file names before building. Probably something like checking for win32 in the name, or just windows.

Let me know if I can help at all because I'm eager to get the Windows builds working as well 👍

from vscodium.

It seems Windows ci environment is now available on travis: https://docs.travis-ci.com/user/reference/windows/

from vscodium.

@G-Ray yes! I was testing it out this past weekend. Unfortunately there is currently a known issue that the build won't work at all if there are secret environment variables (https://travis-ci.community/t/current-known-issues-please-read-this-before-posting-a-new-topic/264). We have a GITHUB_TOKEN environment variable, so it isn't working yet. Once they fix that, I'm excited to see if it's easier to work with than AppVeyor.

cc @TimothyDJewell

from vscodium.

Hey I was interested in fixing the issue for Windows builds, but I see that AppVeyor is paid and Travis still has the secrets issue... Can we try using Azure DevOps? It's free for 10 parallel builds... @stripedpajamas @TimothyDJewell

from vscodium.

@pavanagrawal123 AppVeyor is free for public repositories, lots of open source projects rely on it.

That said, Azure Pipelines is worth trying since it features higher limits and supports all three major OSes.

from vscodium.

@pavanagrawal123 any help is welcome and any platform is fine if it produces working Windows builds :)

from vscodium.

@Calinou whoops just noticed it says "free for open source" in big letters

@stripedpajamas sure, will try my hand at Azure Pipelines!

from vscodium.

@stripedpajamas and @Calinou I have successfully got Azure Pipelines working! 64bit builds are working on Windows :)

How do y'all suggest I publish the artifact onto GH?

from vscodium.

I'm not sure how releases work in Azure. Most likely you will need a personal access token as an environment variable like we have in the Travis build. If you want you can go ahead and open a PR and then we can continue improving it together.

from vscodium.

(also THANKS for your help so far, I'm very excited for Windows builds) @pavanagrawal123

from vscodium.

Alright, that's what I was thinking as well. I'll clean up a few things and submit the PR in a couple of hours!

from vscodium.

Opened #58. Still doesn't push to GH releases, but that shouldn't be too hard to solve.

from vscodium.

Any plans tfor release?

from vscodium.

@pavanagrawal123 Hey thanks, I will take a look at them.

from vscodium.

Is this fixed by #58?

from vscodium.

@JL2210 waiting to see if the windows builds succeed and upload.

from vscodium.

@pavanagrawal123 build worked for me

from vscodium.

Any chance of getting the 1.30 Win builds?

thanks

from vscodium.

@stripedpajamas did you figure out what the issue was?

from vscodium.

Two things-- the build is broken and the scheduled builds don't run. Working on part 1; part 2 might not be fixable. Might need to migrate Windows builds over to AppVeyor

from vscodium.

@stripedpajamas we should be able to trigger with a webhook or something though right? also, what's broken on the builds?

from vscodium.

@stripedpajamas thanks for the follow up

from vscodium.

from vscodium.