Hiya, actually that's the way it runs and also should continue to do. The job queries different sources from us and suppliers and then composes a document that contains a rather big set of version information and tickets with solved issues and then commits the genrated files to the repository before tagging.
But there are some occassions where we have to add special content. This happens more regular when we have entered the final hot phase of a project. The content can be of 2 kinds. Disclaimers (e.g. not allowed for productive systems because no license agreement has been made yet) which I solved with templates and custom text (e.g. after building and testing was some kind of serious bug discovered). I need to drop the custom text into text files in the workspace. You may now ask "Why don't you then do it?" Answer: "Because..." ;) The entire process to provide a software with all steps included to deliver was highly complex. Actaully that complex that 1 integrator had this as fulltime job and the stand-in always feared the day the integrator leaves for holliday or simply quits. It was planned that I get 6 weeks (!!!) of introduction to the build process as I started here. I have been working on the system always with the K.I.S.S. principle in mind. The build system is that simple that even the janitor could build software by now. Actually do or testers and testing manager create software by now if I ain't available and the rebuild of software has a high urgency. Adding custom texts breaks the automation and I don't want the need to access a workspace. I see only 2 respectively 3 approaches. Either stream the custom text directly from the jenkins job setup into the file in question, create a template when needed and point in the Jenkins job to that file or directly manipulate the file in question. Each has its own challenges: - Stream custom text directly via a plugin/variable is the most straight forward approach for unskilled users like the testers and everything necessary for a build job is located on one page. The problem is to keep it out of the rest of the build process like getting it passed as build argument length of text and special characters may botch the build. - Simply opening notepad and dropping the text into a text file and giving Jenkins on the job config page a path to the file would be feasible for unexperienced user. The problem I see here is that special characters are dropped into the ant target call and characters would also have to be escaped eventually several times which becomes a challenge for the standard user. A browse button would be nice :) - Directly manipulating the files in the workspace is not possible in an automated process and can only work when generating the documentation manually. The reason is that all files with a possible impact on the release notes content are deleted when the build starts by the release notes generator which in the manual process is no problem as several stops occur while genrating which gives you the time to add the files after initial deletion. Files are deleted in the workspace and repository too. The reason is that there have been issue with old misleading content as old files haven't been cleared until next release. I have to take a look at the envinject and the conditional build step plugin maybe I can twisted the file functions of these plugins to accommodate my purpose. *gesh* I need to learn java coding to create own plugins :) Take care Jan Am Donnerstag, 28. Juni 2012 11:55:04 UTC+2 schrieb Jan Seidel: > > Hi folks, > > I need an option that allows me to drop special notes into a plain text > file. > This must happen before some Jenkins jobs start to run as that text will > be pasted into release notes. > It must handle hardcoded locations/filenames. > > In best case does each job have its own textarea/editor which points to a > specific file. > I was thinking about plugins. There is afaik a plugin that allows JScript > but I'm not sure if this also applies on pages from jobs. If so a plain > wysiwyg editor could be added if it supports hardcoded paths/file names > (hints about a good editor are highly appreciated). > > It should be located either in the description of a jobs main page or on > the configuration page of the build. > Using the built-in text parameter is not working well. The content is > passed throug the entire build pipeline, prohibits certain characters and > may even wreck the ant calls to build. > I was also thinking about installing a mini web-server and add a link to > that server to manipulate from outside but this is absolutely not my > favorite approach. > > Do you have any ideas, suggestions or even plugins at hand for this task? > > Cheers > Jan >
