Description of problem: Please provide a place in a beaker job to store arbitrary job generator data, eg. command line used to schedule the job. So when eg. cloning a job via UI you can find it in xml offered for the clone. Particularly as I use wow workflow, I can imagine it can easily do the job automatically for users. Some of my 'bkr wow ...' commands are like five and more liners and now I just use bash history & manual copy-paste into tcms... As already discussed on mailing list, data stored is not to be used by Beaker itself anyhow, it is just for convenience of Beaker users. Something similar to job whiteboard. But since whiteboard is already heavily used in other meanings (like 'job title'), we need other such a place. Something like <generator/> or possibly a namespace support so that tools can use any tags within their namespace. Version-Release number of selected component (if applicable): Version 0.16.2
The general concept gets a +1 from me - similar to the recent addition of the "remote_post" metavar, I think some kind of arbitrary "job annotations" capability (whether using XML namespaces or as a dedicated element) would allow Beaker to become a more powerful and flexible platform without significantly increasing the complexity of the core Beaker application.
Independently this need popped up once more in bug 1269105, so it seems there is a real demand for this feature. Please can you take a look once more and raise prio?
I would be more happy with more general solution (like namespaces?) so that that users can easily store a little bit more data in their other use cases, if necessary, without having to add yet another tags via another bugs here.
*** Bug 1269105 has been marked as a duplicate of this bug. ***
Dear David, my apology for the late reply. We're considering expanding the whiteboard field to accept multiple lines (as proposed by https://beaker-project.org/dev/proposals/job-page-improvements.html see Whiteboards). Would that go in the direction you were proposing with this bug?
(In reply to Roman Joost from comment #5) > Dear David, > > my apology for the late reply. We're considering expanding the whiteboard > field to accept multiple lines (as proposed by > https://beaker-project.org/dev/proposals/job-page-improvements.html see > Whiteboards). Would that go in the direction you were proposing with this > bug? Hi Roman, basic direction yes. Not sure this is the best specific route to go. As noted in linked document, whiteboard is now used more or less as title in gui and that fits me very well. Info we would like to store is IMHO not to be consumed by user always, or regularly. I would like to get to it via GUI, but not be visible by default, as it is not needed in all times and could be quite big text. So what about having new 'title' element together with existing 'whiteboard' element?
I think the whiteboard should remain as the human-friendly description. In the new job page we will accept Markdown and show multiple lines, which will be useful I think. But for this RFE, which is really about embedding machine-readable metadata in the job, I think the original idea of having Beaker preserve arbitrary elements in other XML namespaces is the nicest one. For context, here was the original thread where we discussed it: http://post-office.corp.redhat.com/archives/beaker-dev-list/2014-June/msg00051.html
To keep the implementation simple, I would start out by only allowing the arbitrary elements at the top level inside <job/>, like this: <job> <options xmlns="http://example.com/mytool">--distro RHEL6</options> <whiteboard>Running tests on RHEL6</whiteboard> ... where the <options/> could be any arbitrary XML element including any other arbitrary XML content, which Beaker will store as is. So it would be possible to store actual structured data in there too if desired. Then when viewing job results XML the same elements will be included. It wouldn't preserve the *order* or *position* of the elements within <job/> because Beaker doesn't store things that way. They would always be dumped out at the top in arbitrary order. Should Beaker also preserve the extra XML elements when cloning a job?
(In reply to Dan Callaghan from comment #8) > To keep the implementation simple, I would start out by only allowing the > arbitrary elements at the top level inside <job/>, like this: > > <job> > <options xmlns="http://example.com/mytool">--distro RHEL6</options> > <whiteboard>Running tests on RHEL6</whiteboard> > ... > > where the <options/> could be any arbitrary XML element including any other > arbitrary XML content, which Beaker will store as is. So it would be > possible to store actual structured data in there too if desired. > > Then when viewing job results XML the same elements will be included. It > wouldn't preserve the *order* or *position* of the elements within <job/> > because Beaker doesn't store things that way. They would always be dumped > out at the top in arbitrary order. > > Should Beaker also preserve the extra XML elements when cloning a job? I would be very happy with this proposed solution. We should definitely preserve these extra XML elements when cloning a job. It is kind of a property of the job and it should be user's responsibility to clean/modify these elements when needed. Do you have some ETA when we can expect implementation?
Dear David, I'm picking this one up and work on it. A conservative ETA is early next year. I'll keep you posted on the progress on this bug.
Thank you Roman, I am happy you will be working on that.
First patch set is up: https://gerrit.beaker-project.org/#/c/4478/1
This bug fix is included in beaker-server-22.0-0.git.110.c41cd4c which is currently available for testing here: https://beaker-devel.app.eng.bos.redhat.com/
Beaker 22.0 has been released.