Run ggtracker in Vagrant #20
Conversation
|
Hi! This is very cool, thanks!
|
|
|
OK, this is awesome, if you run into any troubles plz don't ping me early & often! |
|
Ok, so I've learned things about Bundler in this process. :-) Turns out I approached Gemfile.lock from the wrong side, so now it's way less changes to have it working with vagrant. Now rspecs are also running - I have not tried with testacular - not sure if it makes sense. I will move Vagrantfile and setup-vagrantbox.sh to new 'stack' repo, so it will be just gem and readme changes that need to be merged here. I just leave everything here for now to allow others to have a look until the other repo is fully working. |
|
great! don't worry about testacular at all, i don't use it, it is totally vestigial and can be removed. |
| * Run `vagrant ssh` to ssh into the vagrant box | ||
| * Run `ssh-keygen` in the vagrant box to generate ssh-keys for github | ||
| * Upload your public keys to Github | ||
| * Clone `ggtracker` project to `vagrant` user's home directory in the vagrant box |
There was a problem hiding this comment.
It is not necessary to generate ssh-keys in vagrant. The folder containing the Vagrantfile is accessible at /vagrant in the VM. A few less steps to repeat when creating the virtual box again.
There was a problem hiding this comment.
Nevermind, that results in errors when running bundler. I should try things before I make comments. :) However, maybe it is possible to use https for cloning? New to bundler, so please ignore if appropriate.
|
Thanks for doing this. I was able to get a local instance of ggtracker up and running in ~30 minutes. I skipped the ssh step by replacing any '[email protected]:' with git://github.com/'. |
|
Oh and I would like to point out that i had to install foreman manually before starting the web server: |
|
Thanks for the git learnings. I was also surprised that I needed keys to clone repos - will try with https instead. I agree, we shouldn't need to clone this repo twice, hopefully my stack-project (a repo with one Vagrantfile and all the repos as submodules) will help with that. And regarding foreman, I actually had it in the Gemfile before but it slipped out again. It's in the esdb Gemfile, which is probably why it didn't make it into this one. I'll add accordingly here, so you don't need to install anything manually. |
|
Using your Vagrantfile and setup-vagrant.sh as a boilerplate, I wrote a script to pull ggtracker and esdb as submodules, and then have a script to go through the setup steps. I did notice that foreman was installed automatically, so thanks for clearing up that this is happening in esdb. I can push these scripts over to you if you have a new repo somewhere. |
|
@gravelweb That would be awesome! 😃 I've created https://github.com/nickelsen/ggtrackerstack as an attempt to a parent project - do you think your setup script would fit in there? If so, you're very welcome to pull-request to that. I'm thinking to have the submodules initialized and versioned outside vagrant, since those components are probably where we will make most changes. Then maybe your script could be a part of the setup-vagrantbox.sh or a subsequent script called by the setup script? Or maybe something else - let me know how you see it. Ultimately, I think this stack-repo should be hosted with ggtracker with refs to ggtracker versions of submodules, so everything is coordinated nicely - my repo is just for the initial attempts, hence also referring to my forks of the components, since a few changes are needed to run in Ubuntu 14.04. |
|
I will certainly host it at ggtracker, let me know when it's the right time and i'll clone it over |
|
OK @nickelsen you have full control of https://github.com/ggtracker/ggtrackerstack |
|
Great, thanks - nice to experience that things are moving fast! 😃 This also enables us to switch to Docker as soon as all components are working and synced. |
|
Ok, so I have the whole stack running now in the stack repo with submodules. We need to make a change to sc2reader due to the deprecation of python-pil, but I'm not sure how to proceed with that. As far as I can see, ggpyjobs uses ggtracker/sc2reader.git@4d421471cda8d8605e91d96425445badd36f2e5f which seems to be pointed to by the |
|
Nah, nevermind, I'll just fork sc2reader as well and ref that in my branch of ggpyjobs, then we can see everything working in sync and plan merges and stuff afterwards - don't want to break prod-stuff just yet. :-) |
|
This line complicates things a bit when running with vagrant, since the virtualbox only has an IP and no domain name (at least per default). As far as I understand, this line assumes the service is reached on a domain, e.g. ggtracker.com, which fails when the location is just an IP. My work-around is to set a hostname for the ip in /etc/hosts on my mac, but it feels pretty invasive as a general solution. @dsjoerg do you think it would be possible to somehow generalize this function/change it to also support hosts with IPs? |
|
The javascript thing is the only thing missing - I was now able to upload replays and see everything locally. This is freaking awesome! \o/ Now we just need a plan for merging the few changes in a backwards-compatible way to avoid breaking production.
|
|
Congrats. I wasn't able to get replays uploaded at all. The spinner wasn't showing and my connection with my aws s3 bucket was timing out. Are you using your own aws account for development? |
|
Yes, I've set up buckets on my own account. Also, note that need to be publicly available for reading and the replays-folder has to be available for writing, as far as I've experienced. I'll put this in the README og the stack project. I run the webapp with Also, you need to set up a hostname for the virtualbox for javascript to run (check with developer console), like All of these things should definitely be refactored/automated/described, but don't require code changes to compile or run. |
|
@gravelweb I've updated ggtracker/ggtrackerstack with my latest changes where all components should compile and run. I first set up esdb and then ggtracker due to some bundler-activation-shenaningans - maybe that can be worked out down the line, so no particular order is needed. |
|
omg this is incredible! @nickelsen regarding the document.domain thing, when you don't do the work-around, what problem does it cause exactly? (i wont be able to get ggtrackerstack up today as my network connectivity is intermittent/crap today, traveling from NYC to Boston on a train) but i will certainly be able to monitor email and answer questions. my guess is that the work-around is the best that can be done. |
|
Great stuff. I hadn't made the s3 publicly available. I'll try that. I did have to make a change wherever the s3 buckets are accessed because it wasn't using the url specified in s3.yml, but rather had s3.amazonaws.com hardcoded. Not sure if you had to make similar changes. |
|
@gravelweb like this? Or did you make a change somewhere else? 669b958 |
|
@dsjoerg When I use the ip, javascript tells me this: |
|
@nickelsen More than just that, actualy. I'm going to need to rebase with your branches and see if I can start pushing changes for review. |
|
@gravelweb Awesome - looking forward to the changes. It's a balancing act with all these submodules, but I hope it can work out, without everybody having to fork everything to work on just one component. |
|
@dsjoerg Looked into the JS thing - looks to be related to Same-Origin policy, which shouldn't be battled, so the work-around probably has to stay. I have moved everything from this PR into the ggtrackerstack repo, so this PR will be closed down the line. To get away from my forks of the components, the following merges are needed into your repos. What would be the best approach to go about this to be as backwards compatible as possible?
|
|
some of the changes are probably harmless, so i'll start reviewing them and do the EZ ones first |
|
@nickelsen all the changes look totally reasonable & quite likely to work in production. Tomorrow I can merge these in & verify that everything works in production. |
|
@dsjoerg Cool - I'll craft the pull requests. |
fix document.domain issue with IP hostnames
I got the webapp up and running with vagrant like this. I have never built ruby apps before, so I don't know if any of the dependencies are borked with the newer versions or why the older locked versions don't work any longer (e.g. unicorn).
I guess, ideally, it should be a different repo with the Vagrantfile and ggtracker, esdb and ggpyjobs as git-submodules, but at least now it's possible to get started. I'm trying to do the same for esdb and ggpyjobs - not there yet, though.
I hope to get to a place where we can work on the timing issues.