Using Buildr within Docpad - docpad

I'm using DocPad to build my website, and in the docs it's saying that we can use an helper called buildr to bundle, compress files.
Is it possible to integrate buildr execution within the command docpad generate or docpad run?
Also does it needs it own config file buildr.coffee or it's possible to write the configs inside the docpad.config plugin section?

I imagine it would be more or less the same as this gist for grunt except with the grunt stuff changed to buildr.

Related

Error: Could not find or load main class com.networknt.server.Server error

I have a quick question. Do you have a light-4j framework docker image hosted somewhere in which I can just add my API jar and run docker? I am getting a hard time running my APIs generated using codegen CLI in docker. It consistently gives me Error: Could not find or load main class com.networknt.server.Server error
Have you tried mvn clean install exec:exec? If you want to run with the jar file, you need to build with mvn clean install -Prelease to generate the final fat jar.
This is one of the features contributed by one of the members to speed up the testing cycle to avoid building all extra artifacts for each cycle. It might confuse new developers, though. The generated README.md has some information on how to build and start. Let me know it is not clear, and I will add extra info. When you run the build.sh to generate a docker image, it will be built with -Prelease in the script.

Heroku, golang asset compilation should happen during builds. But how?

I'm using Heroku and Golang.
I have one or many .scss files and I use a golang library to generate a .css from them.
What I don't understand is how to generate the .css file during Heroku build step.
As stated here https://devcenter.heroku.com/articles/release-phase#design-considerations:
Asset compilation should happen during builds considering the dyno filesystem is ephemeral.
I don't want to commit my generated files.
Am I wrong?
Heroku supports Docker deploy https://devcenter.heroku.com/categories/deploying-with-docker
It means that any transpilations you can do on "Docker build" step

Ansible module documentation on RTD?

We have a set of Ansible modules on GitHub (https://github.com/zhmcclient/zhmc-ansible-modules) and can generate HTML documentation from it using Sphinx. However, the build process includes a step where a documentationgenerator tool from Ansible is run to generate .rst files from the Python module source.
We have set up an RTD project for this (http://zhmc-ansible-modules.readthedocs.io/), but that extra step is not run there, of course.
-> How can we get that extra step run within the build process that runs on RTD?
RTD does not support intermediary steps in its build process. You must provide source files in your repository that are ready to be rendered. See RTD Build Process.

Makefile to gradle conversion for golang application

I have a go lang application which exposes a rest API and logs the information to DB. I am trying to convert the make file to gradle build. Is there any default way similar to maven2gradle plugin or the gradle build file should be written manually? I checked the syntactical differences between gradle and make file but still not clear about passing run time arguments to gradle that is similar to
run:build
./hello -conf=/apps/content/properties/prop.json -v=0 -logDest="FILE" -log_dir="/var/log/logdir"
hello is my executable and others are the runtime arguments. This is my first attempt in migrating make to gradle and I couldnt find any clear documentation. Please help.
As far as I have checked, there is no direct plugin that could do this task. As a workaround, the build execution could be written as seperate tasks in gradle and ordered accordingly. Tasks here would contain setting Go path, installing dependencies and building the application and would be run as command line process in Gradle. Gradle provides support to run command line processes as described in gradle documentation. Hope it helps.

What is the recommended directory structure for Grunt projects

I am setting up a Grunt project for the first time. Is there a recommended directory structure? For example, keep sources under /src, intermediate build artifacts in /stage and final concatenated, minified artifacts in /dist.
I am also using compass/sass. I assume my scss files should go under /src, but what's the correct way to set up the build workflow so that I am building and testing quickly while not cluttering my source directory with build artifacts.
I just have /src and /build (which is your /dist), and no /stage. I haven't found a real need for stage, probably because I don't have much integration testing to do. Let me know what you're using /stage for -- I'm curious. :)
/myproject
/build
/src
/css
/sass
I do have both a /sass and a /css. /css holds the single main.css compiled w/ SASS. In my Gruntfile.js, I have 2 SASS targets, sass:dev & sass:build. sass:dev compiles into /src/css and sass:build into /build/css. /src/css/main.css is git-/svn-ignored.
At the end of the day, Grunt doesn't care how you organize your sources. It just assumes Gruntfile.js and /node_modules are at project root, and that's it. It's actually NPM that assumes package.json's at root.
So, try different structures and settle on one that you like, which always depends on what tools you use.
Hope this helps! :)
Running grunt init:jquery or grunt init:node should give you a pretty good start on answering this question.
Here is the result of running grunt init:jquery inside a directory called init_test and selecting the default answer for grunt-init's prompts.
Writing CONTRIBUTING.md...OK
Writing grunt.js...OK
Writing libs/jquery/jquery.js...OK
Writing libs/jquery-loader.js...OK
Writing libs/qunit/qunit.css...OK
Writing libs/qunit/qunit.js...OK
Writing README.md...OK
Writing src/init_test.js...OK
Writing test/init_test.html...OK
Writing test/init_test_test.js...OK
Writing LICENSE-MIT...OK
See https://github.com/gruntjs/grunt-init

Resources