Docker integration

[Awk34]

No description provided.

[Awk34]

@JeremyMarshall I fixed the commit subjects for now. Make sure to conform to the Contributing Guidelines in the future.

[Awk34]

@JeremyMarshall would you look over my commit, and add some documentation here?

[JeremyMarshall]

Hey sorry I thought I had responded.

I couldn't get the docker generator to work on my setup after the changes. I tried upgrading node but it just wouldn't even see the generator

[Awk34]

Yay, he's alive!

@JeremyMarshall would you please check against that commit I just pushed?

[JeremyMarshall]

@Awk34 seems still to be broken

$ yo angular-fullstack:docker
events.js:141
      throw er; // Unhandled 'error' event
      ^
ReferenceError: genBase is not defined
    at Generator.initializing (/Users/jeremymarshall/src/node/generator-angular-fullstack/generators/docker/index.js:55:14)
    at Object.<anonymous> (/Users/jeremymarshall/src/node/generator-angular-fullstack/node_modules/yeoman-generator/lib/base.js:431:23)
    at /Users/jeremymarshall/src/node/generator-angular-fullstack/node_modules/run-async/index.js:26:25
    at /Users/jeremymarshall/src/node/generator-angular-fullstack/node_modules/run-async/index.js:25:19
    at /Users/jeremymarshall/src/node/generator-angular-fullstack/node_modules/yeoman-generator/lib/base.js:432:9
    at processImmediate [as _immediateCallback] (timers.js:383:17)

after adding the missing import

$ yo angular-fullstack:docker
Creating Dockerfile
Building dist folder, please wait...
A valid Gruntfile could not be found. Please see the getting started guide for
more information on how to configure grunt: http://gruntjs.com/getting-started
Fatal error: Unable to find Gruntfile.
events.js:141
      throw er; // Unhandled 'error' event
      ^
Error: Command failed: /bin/sh -c grunt build
    at ChildProcess.exithandler (child_process.js:213:12)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at maybeClose (internal/child_process.js:818:16)
    at Socket.<anonymous> (internal/child_process.js:319:11)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at Pipe._onclose (net.js:469:12)

@adambarthelson I was thinking the dist folder would be pushed to a separate repo which can then be used as a source in https://hub.docker.com/ (see Automated Builds in here https://docs.docker.com/v1.8/userguide/dockerrepos/) so any changes pushed to it will trigger a rebuild in docker. Similarly upstream changes will also trigger a rebuild

[Koslun]

@JeremyMarshall Grunt has been removed as a choice on the canary branch so think you should probably change the gruntBuild() in docker index to gulpBuild() and run gulp build rather than grunt build.

[JeremyMarshall]

@Awk34 seems it works if you select grunt when configuring so I think as @Koslun suggests it should swing both ways depending on what was initially configured.

[Koslun]

@JeremyMarshall This is currently being merged to the canary branch and as I tried to state above, the canary branch does not have a grunt file. So I think I'm more suggesting it should preferably work in gulp as that's what we're using on the canary branch and 4.X release.

Could leave in a working grunt function/configuration too but would have to back-port it to the 3.X branch to test it here. Either way there is the possibility that we'll get around to supporting grunt again in the future so guess you could leave any grunt functionality there for that purpose.

[Awk34]

^^ context, canary contains all the changes for 4.0.0 right now, including removing Grunt

[JeremyMarshall]

I stole that code from the openshift generator.

@Koslun So when is 4.0.0 expected to release? I can back-port the change if its going to be some time.

Probably off topic but how will you manage people upgrading if they are currently using grunt? Thats what I did as I ran yo angular-fullstack and just accepted to reuse my existing config which was grunt based

[Koslun]

@JeremyMarshall Think 4.0.0 is pretty close. The biggest thing, webpack support, is pretty much done and most of the other stuff seem pretty close too. @Awk34 has the final say but I would probably expect to release this month at least.

Can see the discussion regarding dropping grunt or not here in issue #1869. Would say the general consensus was that it would enable us to get to Angular 2 considerably faster which we figured would convince most people to embrace the change.

For people upgrading from grunt they'll just obviously have to use the new gulp file instead and adjust for any project-specific requirements themselves. However given the significant changes from 3.x.x to 4.x.x even the gulp file has changed considerably so don't think it's necessarily much more difficult for anyone using grunt to upgrade. Think the difficulty will rather be with adjusting anything in webpack, especially adding new dependencies and upgrading the rest of your code, depending on what version you were using previously.

Either way, as stated previously, figure the faster Angular 2 support is worth it.

[AmirGilboa]

@JeremyMarshall thanks for all your work on the docker integration! this might be a game changer for many of us. When this will be integrated into the main stream, can you please give us some walk-through, guidelines, or instructions on how to use it? I have read stuff about docker, it sounds amazing, but i don't have any experience with this. So any tip would be valuable.

[Awk34]

@JeremyMarshall I'm planning on moving forward with Docker integration soon, but I'm not sure about the approach that you took: a Dockerfile released for each generator release, in a separate repo, with a separate subgenerator, etc. I think it would be a much simpler approach to just add the option for docker, and include the complete Dockerfile in the root of the project.

[JeremyMarshall]

@Awk34

What I was looking to do was reduce the cycle time of rebuilding the docker
image. If all the dependencies are baked in then it builds much quicker for
an actual app container. The actual work of doing that will be done on the
docker hub infrastructure too reducing band width for end users

Plus you can also check that the actual generators build something which
can be deployed with Docker.

As there is a Dockerfile in the dist directory then people are free to
customize it to their needs anyway.

The bit which I was having trouble with was getting circleci to build it as
its in as a deployment step but never gets run as the build is failing tests

Incidentally, the docker image is pretty big as it needs to include python
and a full build chain for some compiled modules

JEremy

On Sun, Oct 9, 2016 at 4:43 PM, Andrew Koroluk [email protected]
wrote:

@JeremyMarshall https://github.com/JeremyMarshall I'm planning on
moving forward with Docker integration soon, but I'm not sure about the
approach that you took: a Dockerfile released for each generator release,
in a separate repo, with a separate subgenerator, etc. I think it would be
a much simpler approach to just add the option for docker, and include the
complete Dockerfile in the root of the project.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1965 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACjgyKbPDhWf3eBvcA4_4dw47LmWOaPiks5qyH8bgaJpZM4IyHZs
.

[Awk34]

closing in favor of #2290