Separate configured params to new asciidoc

[vihaanthora]

Addresses the problem associated with #203
Added a line to create the new folder in allAscii.zip. Rest everything remains the same.

@MarkEWaite kindly review this and let me know if it gets a green flag. I'll also test the allAscii.zip generated from this build against the make script of jenkins.io.

[vihaanthora]

I can confirm that the AsciiDoc within the new allAscii.zip contains the expected content now.

[MarkEWaite]

This looks good to me, though I've not run a test to confirm it is well-behaved.

Is there a reasonable way for me to perform an end to end test on my development machine before it is merged?

[vihaanthora]

Is there a reasonable way for me to perform an end to end test on my development machine before it is merged?

I can describe the way that I tested it. I downloaded the allAscii.zip file and unzipped it in the pipeline/steps/ folder of jenkins.io. Then I commented that particular information from being fetched as an external resource, and run make all. Any inconsistency in the syntax of asciidocs would have been caught here (like the error present in the previous PR). To test if the generated documentation is exhaustive of all the existing documentation, I searched the original documentation for the configured class names to ensure that they follow all the rules mentioned in the README. I tested the links by going to Pipeline: Multibranch > resolveScm > fromScm > scm > MultiSCM > GitSCM.

I can explain some interesting parameters included in config.txt in the next docs office hours, and also discuss what else can be configured to lighten the site up the furthermore.

[MarkEWaite]

I can describe the way that I tested it.

That was a great description. Thanks!

I'm about to go offline for the rest of the day. If you're available to check the build results over the course of the next several hours, I could merge this and then after this is built and the allAscii.zip is available, I could merge a jenkins.io pull request to cause the build to run. However, I won't be able to take action if it fails.

Considering how late it is in your time zone, I think we should wait for the merge until tomorrow. What's your preference @vihaanthora ?

[vihaanthora]

Yes @MarkEWaite, I think we should take it forward tomorrow, and we can also use the docs office hours to facilitate the merge process if required.