I have updated my template with the code that pulls the files from github .
Some of the assumptions that I have made :
1. All plugin repositories have the keyword "plugin"
2. The plugins are affiliated with github.com/jenkinsci
https://docs.google.com/document/d/1EHX0DJ8alsctFN6POLCeho
(replies inline)
On Wed, 01 Jun 2016, Oleg Nenashev wrote:
> Yes, raw HTMLs :(
>
> Do you have regular team meetings in this project.
> I have a bunch of questions regarding the plugin documentation format (the
> document is not detailed enough), and maybe a short chat is better than a
> long re
I can set one up
On Wed, Jun 1, 2016 at 8:20 PM, Oleg Nenashev
wrote:
> Yes, raw HTMLs :(
>
> Do you have regular team meetings in this project.
> I have a bunch of questions regarding the plugin documentation format (the
> document is not detailed enough), and maybe a short chat is better than
Yes, raw HTMLs :(
Do you have regular team meetings in this project.
I have a bunch of questions regarding the plugin documentation format (the
document is not detailed enough), and maybe a short chat is better than a
long review-change-review cycle.
BR, Oleg
2016-05-31 17:28 GMT+02:00 Baptiste
Hi,
Sorry should already have reviewed the gdoc. Will do this evening.
In general, please don't hesitate to ping me e.g. on irc as a reminder to
some thread or things you're expecting an answer from Tyler or me.
See below for the current email.
Le 31 mai 2016 12:30 PM, "Cynthia Anyango" a
écri
@Oleg ,
- How would you suggest I handle the exploit injection issues plus what is
RAM HTML ? :)
I feel i would need some help with that @Tyler and @Baptise
- How to write multi-page documents
I have found pandoc.org which renders multiple files into a single file .
for example
1.gettin
Hi Cynthia,
Thanks for sharing the document! I've added several comments. It definitely
requires much more details. My main questions would be:
- How to handle the embedded content?
- How to secure Jenkins website from exploit injection into ASCIIDOC?
(e.g. via RAM HTML)
- How to writ
Hello everyone ,
I have put up together a document containing some of the things that will
go into various doc files . Please feel free to comment and put up as many
suggestions as you can .
https://docs.google.com/document/d/1EHX0DJ8alsctFN6POLCehowusuikmnUMeL_5jPHVURA/edit?usp=sharing
Th
@Baptise I have gone through more than 20 plugin repos(am still going
through more) trying to come up with a standard template , I will share the
google soon
On Tue, May 24, 2016 at 11:00 PM, Baptiste Mathus wrote:
> Hi Cynthia,
>
> Not sure Oleg was referring to a specific plugin, more he's wil
Hi Cynthia,
Not sure Oleg was referring to a specific plugin, more he's willing to
convert his plugin docs to asciidoc IIUC.
If you already know markdown, then you can consider Asciidoc being quite
the same, but being more /standard/ and with more features.
If you want examples of actual asciidoc,
Hey Oleg ,
Could you please refer me to a plugin that has its documentation in
Asciidoc
On Sunday, May 15, 2016 at 5:38:35 PM UTC+3, Oleg Nenashev wrote:
>
> In Jenkins.io we support both Markdown and Asciidoc.
> Asciidoc is recommended, because we use it's macros features for
> particular ca
If we try so summarize:
- Keep It Simple (so that there's a very high chance the APD project
does not end being ignored by most developers because it's too much hassle
to use)
- Not having to release, say, a 1.3.x to fix some typo or whatever in a
1.3 version" (probably a corollary
I certainly agree that pulling docs from master is the wrong approach. Just
like pull the code from master and just building a plugin would be wrong.
On Fri, May 20, 2016 at 3:07 AM, Cynthia Anyango
wrote:
> But I do not want to confuse users with documentation that does not match
>> a released
If you simply mark new features with the version number they were/will be
introduced in, then users will not be confused by the appearance of a
feature in documentation that they do not see in the product. In fact
arguably this mode is better for users because they can see what features
are schedul
> On 20.05.2016, at 12:07, Cynthia Anyango wrote:
>
> Are there any plugin developers who feel the same as @Daniel ?
Would it be possible to offer a branch (named by convention, e.g.
jenkins-site-docs) as option, and if it doesn't exist, fall back to master?
--
You received this message b
>
> But I do not want to confuse users with documentation that does not match
> a released plugin. Pulling the docs from master would be a no-go for me.
> The master branch may contain work in progress and I do not want to cut a
> release just to keep the docs consistent or up-to-date. Pulling the
On Tue, May 17, 2016 at 3:26 PM, Robert Sandell
wrote:
> I don't think we should have to rely on having to make a release just to
> get a fix into the documentation.
> The doc generation should be just picked from the master branch during the
> static generation of jenkins.io unless that would ta
>
> But I don't want to have to release a new version of my plugin just
> because I updated the tutorial or tips & tricks sections.
> The new feature bug is present in today's wiki usage as well.
>
So there could be a manual documentation publishing trigger. Then owners
will be able to get the new
But I don't want to have to release a new version of my plugin just because
I updated the tutorial or tips & tricks sections.
The new feature bug is present in today's wiki usage as well.
/B
On Tue, May 17, 2016 at 5:57 PM, Cynthia Anyango
wrote:
> I agree with @Oleg ,
>
> One of the important
I agree with @Oleg ,
One of the important aspect to this project is to ensure that plugin
documentation remains up-to date
On Tuesday, May 17, 2016 at 5:22:22 PM UTC+3, Oleg Nenashev wrote:
>
> I don't think we should have to rely on having to make a release just to
>> get a fix into the docu
I think instead of relying on specific file names only it would be better
to rely on pulling in all files in a specific directory for the
documentation site. E.g. src/main/documentation or whatever.
On Tue, May 17, 2016 at 4:16 AM, Cynthia Anyango
wrote:
> Hey Manfred ,
>
> Thanks for your fee
>
> I don't think we should have to rely on having to make a release just to
> get a fix into the documentation.
> The doc generation should be just picked from the master branch during the
> static generation of jenkins.io unless that would take too much time.
> That way a pull request with a new
I don't think we should have to rely on having to make a release just to
get a fix into the documentation.
The doc generation should be just picked from the master branch during the
static generation of jenkins.io unless that would take too much time.
That way a pull request with a new feature in i
Hey Manfred ,
Thanks for your feedback ,
We are going to prototype both asciidoc and markdown the results of the
will be hosted on jenkins.io which supports both .
I will prepare a plugin subsection in the Documentation section
https://jenkins.io/doc/
this is where all the plugin docs will
In terms of asciidoc (and doc in general) usage for plugins I can see a
number of ways for this to work.
1. Just write the docs and rely on the rendering in github. Similar to a
readme being rendered just fine github renders any asciidoc or markdown
files. E.g. see
https://github.com/simpligility/
In Jenkins.io we support both Markdown and Asciidoc.
Asciidoc is recommended, because we use it's macros features for particular
cases.
If you need any reference plugin with documentation in Asciidoc, please let
me know.
I consider moving docs for several plugins to GitHub, so I can migrate one
I am all for asciidoc first, its the better format after all ;-)
On Mon, May 9, 2016 at 1:53 PM, Baptiste Mathus wrote:
> +1 Manfred.
> IMO, this could even be asciidoc first, and possibly some Markdown flavour
> (prolly GH's) secondly.
>
>
> 2016-05-09 21:24 GMT+02:00 Manfred Moser :
>
>> I su
+1 Manfred.
IMO, this could even be asciidoc first, and possibly some Markdown flavour
(prolly GH's) secondly.
2016-05-09 21:24 GMT+02:00 Manfred Moser :
> I sure hope this will work with asciidoc as well as markdown files ;-)
>
> On Mon, May 9, 2016 at 10:54 AM, Cynthia Anyango <
> acynthiaanya
I sure hope this will work with asciidoc as well as markdown files ;-)
On Mon, May 9, 2016 at 10:54 AM, Cynthia Anyango
wrote:
>
> Hey Martinda ,
>
> Thanks for your feedback .
>
> All that you have mentioned is within the scope of my project .
>
> As @Daniel mentioned I will be introducing vari
Hey Martinda ,
Thanks for your feedback .
All that you have mentioned is within the scope of my project .
As @Daniel mentioned I will be introducing various named-by-convention
files that will define all that should be contained in a plugin
documentation . All the plugin documentation will
> On 07.05.2016, at 01:00, martinda wrote:
>
> As a plugin user, and as a very occasional contributor, what would help me
> document plugins better and faster would be to know where the documentation I
> put in the code ends up on the web, and where to put the documentation in the
> code (the
Hello Cynthia,
As a plugin user, and as a very occasional contributor, what would help me
document plugins better and faster would be to know where the documentation
I put in the code ends up on the web, and where to put the documentation in
the code (the help*.html files).
I don't know if thi
Hey everyone .
My proposal for the GSOC project : *Automatic Plugin Documentation was
accepted*!
Thanks to everyone who helped me out . The help really came a long way to
getting the project accepted .
During summer , I will be working on grabbing plugin documentation from the
github readm
33 matches
Mail list logo