Any way to test?

[Zearin]

I’m interested in improving the styles (and I love that you wrote them in Stylus! ☺).

But since the site is stitched together from a few repositories, I don’t know how to tell if my changes break the build or not.

Is there a way for me to test the build? (Sorry if it the answer is obvious, but I’m still learning Node/CoffeeScript conventions…)

[greduan]

I would be interested in this as well. :)

[Zearin]

@docpad/documentation-team ping

[balupton]

We currently have no automated testing setup. However, it certainly is possible. If someone wants to do this, that will be cool. Probably best doing it as a guide, as @mikeumus is working on redoing the website.

[balupton]

If this is referring to manual testing, you can clone out this repo, cd into it, do a npm install, a cake watch, and you'll be able to test locally.

[Zearin]

If this is referring to manual testing, you can clone out this repo, cd into it, do a npm install, a cake watch, and you'll be able to test locally.

Okay. But, how would I make those commands pull in the changes from my local docpad-documentation repo?

[Zearin]

(Sorry if that’s a “silly” question. ☺ I’ve never really tinkered with cake…)

[greduan]

Why don't you just do these commands from your local docpad-website repo? :)

[Zearin]

Why don't you just do these commands from your local docpad-website repo? :)

I did. That’s not what I’m asking…

• So, I have a clone of this repository. It is unchanged.
• I also have a clone of [docpad/documentation], with changes.

When I run the above commands, it pulls the documentation down from [docpad/documentation], which is not what I want. Instead, I want it to pull in the modification I’ve made.

Does that make sense?

[Zearin]

Why don't you just do these commands from your local docpad-website repo? :)

Ooops! Now I see why you were confused about what I was asking—I typed the wrong repo in an earlier comment!

Gonna fix that right away…

---

(Fixed!)

[Zearin]

When I do the above commands, it seems to work normally, until cake finally runs DocPad. Then, the first little bit of output (which is reeeeeaaaaaaaally long in total) is this:

coffee watch
docpad run
OK
13:59:21 - compiled /Users/amrogers/Developer/Projects/GitHub/_docpad/docpad-website/app/src/docpad.coffee
13:59:21 - compiled /Users/amrogers/Developer/Projects/GitHub/_docpad/docpad-website/app/src/templateData/navigation.coffee
13:59:21 - compiled /Users/amrogers/Developer/Projects/GitHub/_docpad/docpad-website/app/src/templateData/text.coffee
info: Welcome to DocPad v6.63.8 (local installation: /Users/amrogers/Developer/Projects/GitHub/_docpad/docpad-website/node_modules/docpad)
info: Contribute: http://docpad.org/docs/contribute
info: Plugins: coffeekup, coffeescript, eco, feedr, highlightjs, livereload, partials, repocloner, robotskirt, services, stylus, text
info: Environment: development
info: DocPad listening to http://0.0.0.0:9778/ on directory /Users/amrogers/Developer/Projects/GitHub/_docpad/docpad-website/site/out
info: LiveReload listening to new socket on channel /docpad-livereload
Performing generate: fetch data to render at 3/10 30% ==============-----------------------------------fatal: '../docpad-documentation' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Performing renderFiles (preparing) at 0/1 0% -------------------------------------------------(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.

(EDIT: Fixed markup; it’s code, not a blockquote! ☺)

[Zearin]

@Greduan @balupton Any ideas? I’d love to continue working on this, but I don’t know how to proceed…

[greduan]

The way I would go about this is to clone this repo and it's submodules (which I imagine is the documentation repo). Then make your changes inside this newly cloned docs repo and then compile.

When it's time to push just update the remote it should push to by default and Bob's your uncle. :)

[Zearin]

The way I would go about this is to clone this repo and it's submodules (which I imagine is the documentation repo)

Umm…what submodules?

[Zearin]

(whoops…I submitted the last comment too soon)

The documentation repo isn’t connected to this repo via git submodules. It’s manually pulled in at compile-time by docpad/docpad-plugin-repocloner.

I don’t know why it’s configured that way, but there it is…

[Zearin]

• Line 336 configures the repocloner plugin
• Line 441 regenerates the site on every push to the documentation

[greduan]

Yeah. so just pull that (run it once or something) and make the changes there, and update the remote.

Or you can make the changes in your own repo, commit, and pull the changes from your local repo. Just another idea. :)

[Zearin]

I tried. For whatever reason, it doesn’t work.

I end up with an empty “site”; the main navigation, footer, etc. is there, but none of the content is populated.

Frustrated. :(

[greduan]

I'm afraid I can't provide further advice. :/

[Zearin]

Okay.

Then I will have to take a break from this issue. :(

However, I urge you to leave the issue open. I think this is something that should be simple, but isn’t. That is a barrier for some contributors, and—I hope you agree—such barriers need to be eradicated.

Although it makes sense to separate the website from the content, the fact remains that there is still a degree of coupling that cannot be avoided in all situations.

In my case, I made a few somewhat strong changes to the markup, and I wasn’t sure how they would render. Some contributions to the documentation are no-brainers…but others need to be rendered and checked before a contributor opens a pull request. This is one such use case.

Personally, I would consider labeling this a “bug”—not in the traditional sense, of course! But, a “bug” in terms of developer usability. I get the sense that you guys really want to welcome contributions to the DocPad project. But, for situations like this one, it is not obvious how to check whether changes to the the documentation markup will render properly. That’s not a “bug” that stops the software from doing what it’s supposed to, but it’s a “bug” that prevents the software from growing like it’s supposed to.

Please look into fixing this for myself, and for other would-be contributors. Thanks!

[greduan]

Thank you for your contributoins Zearin, I agree with you and in today's catchup (if it happens) I'll bring up this topic. :)

[balupton]

npm test can now be used, as seen by our new travis workflow