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

Road Map #19

Open
2 of 5 tasks
reconbot opened this issue Apr 11, 2016 · 3 comments
Open
2 of 5 tasks

Road Map #19

reconbot opened this issue Apr 11, 2016 · 3 comments

Comments

@reconbot
Copy link
Member

reconbot commented Apr 11, 2016

We have a few different parts of the project.

  • The cross compiler: takes a package and version and produces a tarball of the package with a .node compiled to run on the tessel. Current status: Works for some packages and not others.
  • The package service. Current status: Using amazon s3, it's great.
  • The status service: Listens to npm for new publishing and determines if it's a package we care about and if we've got a build
  • The build service - automatically builds packages to work on the tessel as the status service discovers them, and stores them on the package service.
  • The test service? - tries to require packages that are cross built on arm hardware to see if they actually work and/or their tests pass.

I have a branch npm-feed where I started a spike of the status service. All of this is up for review and change. If you've got a different idea you'd like to try to get the job done, lets take a look at that too.

cc @soldair

@Student007
Copy link
Member

  • Document how it works in the README.md

@reconbot I put my two cents in here 😄

@Student007
Copy link
Member

  • The progress report / state - a list of state and comments about what is necessary to do to make a special package work. Also it should link related discussions.

@reconbot
Copy link
Member Author

Today I updated our "cross compiler" to decouple it from vagrant and add docker support. We now have an image that will cross compile package binaries. For those not so familiar with docker, it lets us treat the whole "VM" as a single command. It works and it will run anywhere we host our server. (unlike vagrant) It also has the advantage of being disposable, each package build is isolated from the next and from the host system. This negates a possible security problem (hacking build servers through gypfiles).

Both the vagrant and docker compile commands use the same core script. I recommend we use docker as it's quicker to use and setup, but there's a low overhead maintaining both.

Now we that we have a "command" that produces compiled packages, the build server will be much easier to build.

@reconbot reconbot changed the title [draft] Road Map Road Map Jun 13, 2016
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

2 participants