Hi, We need something that can be fetch and parsed during site generation, by a Jenkins pipeline build (groovy), by the cron apidoc stuff.
I would also request that we use named key instead instead of a simple array. I will put the onliner Jenkinsfile on the git in the nbbuild/jenkins folder for the branch so I can do some investigation not hurting much. Regards Eric -----Message d'origine----- De : Geertjan Wielenga <[email protected]> Envoyé : jeudi 16 mai 2019 06:17 À : [email protected] Objet : Re: apidoc production rewrite +1 to further automation! Gj On Wed, 15 May 2019 at 21:14, Antonio <[email protected]> wrote: > Hi all, > > I think it's a good idea to have a file somewhere that contains > information about each of our releases, but I'd rather use JSON, YAML > or XML. > > Currently for each release we have to generate download pages (*) with > very specific information: links to source zip downloads, branch name, > links to SHA & KEYS, links to mailing list archives for votes and > results, etc. All that info is mandatory on each release. > > If we had such a file we could generate the download information using > JavaScript, for instance, so users could choose which version to > download and see all appropriate links. > > So +1 to the idea to have this release metadata somewhere, but I'd > rather use other format. > > Cheers, > Antonio > > (*) > http://netbeans.apache.org/download/nb90/nb90.html > http://netbeans.apache.org/download/nb100/nb100.html > http://netbeans.apache.org/download/nb110/nb110.html > > > El 15/05/2019 a las 20:26, Eric Barboni escribió: > > Hi, > > (sorry for clarity) > > At the current time we use separated build configuration present > > over > here > > to generated the apidoc. > > > https://github.com/apache/netbeans-tools/blob/master/buildscripts/conv > enienc > > es/generated/ > > A build as to be created for each release. It's a bit hard to > > maintain > and > > uncorrelated to netbeans git. > > > > I would like to test a new type of build (Apache Hosted Git Folder, > > kind > of > > multibranch). > > The job will scan for specific branch like master| release[0-9]* (to > > take only the full release branch, not the patch or so) > > > > Idea is to put a file "nbbuild/Jenkinfileapidoc.groovy" in master, > > and > the > > previous releasebranch. For the future release it will be by > construction. > > This will trigger build per branch. > > The file will be a call to a Jenkins library that we put here > > https://github.com/apache/netbeans-jenkins-lib. > > > > The library will contains all historical information (from release90 > > to > > master) like release date for a branch, human redeable version, url, > jdk, > > tools, and so on and pick information to build apidoc. > > > > Regards > > Eric > > > > > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
