> On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral < kpa...@redhat.com > wrote:
> > > This is what I meant - keeping item as is, but being able to pass another
> > > structure to the formula, which can then be used from it. I'd still like
> > > to
> > > keep the item to a single string, so it can be qu
On Thu, 2017-02-09 at 00:29 +0100, Josef Skladanka wrote:
> On Wed, Feb 8, 2017 at 8:06 PM, Adam Williamson
> wrote:
>
> > Wouldn't it be great if we had a brand new project which would be the
> > ideal place to represent such conventions, so the bit of taskotron
> > which reported the results co
On Wed, Feb 8, 2017 at 8:06 PM, Adam Williamson
wrote:
> Wouldn't it be great if we had a brand new project which would be the
> ideal place to represent such conventions, so the bit of taskotron
> which reported the results could construct them conveniently? :P
https://xkcd.com/684/ :) (I mean
On Wed, Feb 8, 2017 at 7:39 PM, Kamil Paral wrote:
> > I mentioned this in IRC but why not have a bit of both and allow input
> > as either a file or on the CLI. I don't think that json would be too
> > bad to type on the command line as an option for when you're running
> > something manually:
>
On Wed, Feb 8, 2017 at 4:11 PM, Tim Flink wrote:
> On Wed, 8 Feb 2017 08:26:30 -0500 (EST)
> Kamil Paral wrote:
>
> I think another question is whether we want to keep assuming that the
> *user supplies the item* that is used as a UID in resultsdb. As you say,
> it seems a bit odd to require peo
On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral wrote:
> This is what I meant - keeping item as is, but being able to pass another
> structure to the formula, which can then be used from it. I'd still like to
> keep the item to a single string, so it can be queried easily in the
> resultsdb. The item
On Wed, 2017-02-08 at 08:11 -0700, Tim Flink wrote:
> Would it make more sense to just pass in the dict and have semi-coded
> conventions for reporting to resultsdb based on the item_type which
> could be set during the task instead of requiring that to be known
> before task execution time?
Would
> I think another question is whether we want to keep assuming that the
> user supplies the item that is used as a UID in resultsdb. As you say,
> it seems a bit odd to require people to munge stuff together like
> "namespace/module#commithash" at the same time that it can be separated
> out into a
On Wed, 8 Feb 2017 08:26:30 -0500 (EST)
Kamil Paral wrote:
> > This is what I meant - keeping item as is, but being able to pass
> > another structure to the formula, which can then be used from it.
> > I'd still like to keep the item to a single string, so it can be
> > queried easily in the res
> This is what I meant - keeping item as is, but being able to pass another
> structure to the formula, which can then be used from it. I'd still like to
> keep the item to a single string, so it can be queried easily in the
> resultsdb. The item should still represent what was tested. It's just th
Excerpts from Josef Skladanka's message of 2017-02-07 11:23 +01:00:
> On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral wrote:
>
> > The formulas already provide a way to 'query' structured data via the
> > dot-format, so we could do with as much as passing some variable like
> > 'task_data' that would
On Mon, Feb 6, 2017 at 6:49 PM, Kamil Paral wrote:
> The formulas already provide a way to 'query' structured data via the
> dot-format, so we could do with as much as passing some variable like
> 'task_data' that would contain the parsed json/yaml.
>
>
> Or are you proposing we add another varia
> Chaps,
> we were discussing this many times in the past, and as with the
> type-restriction, I think this is the right time to get this done, actually.
> It sure ties to the fact, that I'm trying to put together
> Taskotron-continuously-testing-Taskotron together - the idea here being that
> on
13 matches
Mail list logo
