Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get up and running on Appveyor #174

Closed
flavorjones opened this issue Sep 22, 2015 · 15 comments
Closed

Get up and running on Appveyor #174

flavorjones opened this issue Sep 22, 2015 · 15 comments
Assignees

Comments

@flavorjones
Copy link
Contributor

Appveyor allows us to test for Windows support, to avoid problems like the one solved by #173.

@sschuberth
Copy link
Contributor

Despite this being closed, AppVeyor builds do not pass tests right now due to several issues. After a break, I just wanted to continue working on this again, but I realized @xtreme-vikram-yadav removed the ci/install_*.sh scripts in eae74c0 in favor of a Docker file. However, Windows / AppVeyor does not support Docker natively.

So, what's the plan going forward to support CI on Windows? If the plan is to exclusively use Concourse in the future, does that support Windows?

@flavorjones
Copy link
Contributor Author

flavorjones commented Mar 22, 2017

Concourse does support windows. Not sure what @kdykeman and team are planning for here, but I'd like to refactor the concourse setup to use https://github.com/flavorjones/concourse-gem and a windows worker like the pipelines at https://ci.nokogiri.org.

@sschuberth
Copy link
Contributor

Concourse does support windows.

Interesting. From what I understand, Concourse requires self-hosting, and there's no public service for OSS projects like for Travis / AppVeyor, correct?

In any case, I'll submit my fixes to make tests pass on Windows in general.

@flavorjones
Copy link
Contributor Author

Concourse requires self-hosting, and there's no public service for OSS projects

Also correct. The tradeoff, though, is that you get a ton of flexibility in how and what you run in the pipelines. I'll point again at https://ci.nokogiri.org/ in which Nokogiri is tested under a wide range of situations, including under valgrind; on windows; and (not publicly visible) on OSX. This flexiblity is occasionally necessary and useful.

For example, on LicenseFinder, we found it extraordinarily difficult to set up a working erlang/elixir environment on Travis to support merging #261. That path is now open to us with Concourse.

@kdykeman
Copy link
Contributor

There is a story to stand up a windows concourse worker, but we haven't gotten to it yet. I have to admit, I was somewhat hoping to see a PR come in from others for that.

@flavorjones
Copy link
Contributor Author

@kdykeman I can PR a windows test task into the pipeline. It's on my TODO list.

@sschuberth
Copy link
Contributor

More Windows test fixes are in #294. I believe there's only one more issue on Windows, but I'll double-check one Concourse is running on Windows.

BTW, I have some local improvements to appveyor.yml. Are you interested in getting these merged, or will appveyor.yml go away in favor of Concourse anyway soon?

@flavorjones
Copy link
Contributor Author

If you have changes to appveyor.yml I'm sure they'd be welcome.

But Appveyor is limited in the same ways that Travis is, and so we may have to run an abbreviated test suite on those platforms once we pull in additional support (like erlang/elixir above).

@sschuberth
Copy link
Contributor

The "problem" with my appveyor.yml changes is that they require to restore the ci/install_* scripts that were removed in eae74c0, and I guess you'd not want that, or?

@kdykeman
Copy link
Contributor

@sschuberth we finally got around to adding a windows worker to our concourse deployment - sorry for the delay. The tests are currently failing so we're not yet gating pull-requests on that job passing. I'm guessing the failures are mostly around shelling out and shell brace expansion. Not being terribly windows savvy, I'm wondering if you'd be interested in helping out with getting that job to go green?

You can see the output for a recent run at https://osl.ci.cf-app.com/teams/main/pipelines/LicenseFinder/jobs/ruby-2.3-windows/builds/3

@sschuberth
Copy link
Contributor

@kdykeman, while I'm not actively using LicenseFinder anymore, I'm willing to help WRT Windows support! I'll start filing a few PRs, starting with #353.

@kdykeman
Copy link
Contributor

Excellent! Very much appreciated!

@sschuberth
Copy link
Contributor

@kdykeman, I've figured out why the Bower feature test fails on Windows, but I'm unsure how to solve it. On Windows I get

Dependencies that need approval:
gmaps, 0.2.30, "This package is not installed. Please install to determine licenses."

So gmaps is not installed. But isn't LicenseFinder supposed to install it automatically in order to check the license? Is it pure coincidence that the gmaps seems to be installed on Linux, or do you explicitly do that somewhere?

@sschuberth
Copy link
Contributor

@kdykeman Any comment on my gmaps question above?

@kdykeman
Copy link
Contributor

kdykeman commented Oct 6, 2017

@sschuberth Sorry, I missed your gmaps question until now. I'll need to dig into it a bit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants