Check rake environment

[toch]

• release task depends on compile task
• abort if not in a docker
• abort compile task if toolchain is not present

[zzak]

@toch Could you please rebase?

[toch]

@zzak rebase done

[toch]

Should I have to do something else?

[zzak]

@toch I'm still curious why you had to manually load "#{mruby_root}/test/mrbtest.rake" in the compile task.

This rake task will actually go away once we can merge my patch to extract the test binary stuff upstream in mruby, so your change will actually break (or something).

What happens if you remove it?

[toch]

The error I got was: undefined local variable or method target for main:Object.

I cleaned everything, removed the load, and I ran again docker-compose run compile. I do not have the error ><.

In the next commit, I removed the load from Rakefile and setup.rb.

[zzak]

This will need a rebase as well

[toch]

@zzak done

[kbrock]

@toch would it make sense to have this as a task dependency? Are there rake tasks that may make sense to run locally?

task :docker do
  abort("Not running in docker, you should type \"docker-compose run <task>\".") unless is_in_a_docker?
end

task :compile => :docker

[toch]

I've squashed the commits in two commits: one is about the compile task, the other about the abortion in case of not being run into a docker container. After discussion with @hone, it is possible to disable that check, so ppl that would like to run it locally can.

@kbrock As setting up a cross toolchain is not easy, I think the idea is to not pull the user into that by default. I've added an option to disable that if you want to do it locally. @hone and @zzak am I wrong?

[hone]

@kbrock that's an interesting idea.

@toch that's correct. thanks for squashing. I've added some local tasks. I wonder if this is a use case we should support?

[toch]

@hone

• I just updated my last commit that was buggy
• not sure to follow, what are those local tasks?

[hone]

Just an example of local rake tasks that can be run/added to a project in
addition to the docker stuff. That should maybe be a separate PR though
where we take these tasks and pull them into a separate file for ease of
upgrading.

On Wed, Sep 30, 2015, 7:24 PM Christophe Philemotte <
notifications@github.com> wrote:

@hone https://github.com/hone

• just update my last commit that was buggy
• not sure to follow, what are those local tasks?

—
Reply to this email directly or view it on GitHub
#13 (comment).

[toch]

Just an example of local rake tasks that can be run/added to a project in addition to the docker stuff. That should maybe be a separate PR though where we take these tasks and pull them into a separate file for ease of upgrading.

I think it's a good idea to discuss that in another PR. I don't like to put to many changes in the same PR.

[toch]

Due to the line 14 we load "#{mruby_root}/Rakefile" and because of the root permission on the volume mounted from the container, it wasn't possible to run a local task. So I've tried to get rid of the root permission and come with 694e00e.

The only issue is that the local uid and gid are hardcoded. I didn't find a way to resolve that. Do you know by chance how to do that?

Inspired by @kbrock's idea, after several issues, I ended with the last commit: 79b4a5e

• it's cleaner,
• you don't have to worry, it's checked by default
• it allows to add local task

@hone @zzak what do you think of that new version?

The test failure is the same @hone reported #23 + another one linked to bintest/mruby-cli.rb#setup there is indeed a missing = at line 10, but even after fixing that it still fails as it doesn't find the directory of the new_app. When I use manually mruby-cli, it works correctly. Any idea why?

[zzak]

This should go in the upstream container?

I thought we had issues with this on OS X because how boot2docker deals with permissions

[toch]

This should go in the upstream container?

Of course, I put it there temporally so you can try it.

I thought we had issues with this on OS X because how boot2docker deals with permissions

I didn't know that. I'll try on OS X. thanks for the info.

[toch]

@zzak is it the issue you mentioned boot2docker/boot2docker#581 ?

by the way, new version of docker comes with interpolation, very helpful for a non static UID docker/compose#1532 (comment) (available in docker-compose 1.5)

[toch]

FYI, the last commits should fix the broken tests. (ofc 8f8b76c is temporary)

[toch]

@zzak @hone
Here we go, the commit 02503e6 allows to synchronize the owner/group in Docker with the one of the host. (just the docker-compose shell works for now, that's why the tests fail)

@zzak could you try on MacOSx please?

does one of you has a ready environment on Windows to try it?

[toch]

all docker-compose tasks are supported now, they will be pass to the script correctly setting the environment and the permission according the host permission.

[toch]

interesting. yeah, ENTRYPOINT seems really powerful. if we get rid of docker-compose, we could support windows as well. does your ENTRYPOINT script work on windows?

It's a bash script that is run in the container itself. It should work according my reading, I'll test that asap.

And indeed, that would be nice to just do docker run test. The good think with docker-compose is the mounting of volume.

That'd be nice, but not a deal breaker. It does seem a bit hacky, but I'm +1 if it works. I'm not sure I follow the first bullet point, but I'll take a look at the code.

It does what Docker should do :). Honestly, it's not so hacky, I use only standard tools and bash.

[toch]

According the doc, there is a a directive VOLUME for Dockerfile.

[toch]

I tried to install docker toolbox on my OsX in a VirtualBox ... I have a problem VT-x detection making impossible to run a VM inside a VM. :/

I'll try with a Windows in a VM.

[zzak]

I can test on OS X and I still have a Windows 10 VM available for testing

[toch]

Thanks @zzak!

Would be nice to find a way to test on each platforms easily.

[toch]

follow up of a call I had with @zzak today

it has drifted too much :p
so we keep only the check we are in a docker container and the env var to disable it
in another branch we ll deal with a better way to allow the dev to play with mruby and gems without having to deal with root permissions

[hone]

yeah, the docker root permission stuff should be a separate PR. Let's take that out and I'm +1 for the rest of the PR.

[toch]

@zzak @hone done, and I put the non-root solution for docker here https://github.com/toch/mruby-cli/tree/non-root-docker I'll open a separated PR about that.

[zzak]

@toch Thank you!!

I will test this out! <3

[toch]

rebased onto master to resovle conflict

[hone]

@toch when running the tests b949478 was unnecessary for me. If you look at the capture3 API, it actually takes a *cmd, so it should work fine without this comment. Can you rebase this out and then I'm happy to merge.

[hone]

Merged in eef2885