On Thu, Apr 20, 2017 at 12:07 AM, Adam Williamson <
adamw...@fedoraproject.org> wrote:
> OK, like I said, half-baked =) But wdyt?
>
>
Love it! (And I swear, it has nothing to do with the fact, that I also
thought this would be a great way to solve it in a more generic manner.)
On Tue, 2017-04-18 at 06:35 -0600, Tim Flink wrote:
> One of the things that seems like it is and will be a pain point for
> folks writing package-specific tasks is how to work through the times
> when there was an issue in the task and things didn't run well. At the
> moment, the only solution we
I'd like to see something like:
$ fedpkg test
Unfortunately, internally we are using "$ rhpkg tests" to clone the test
suite into the repo
Vít
Dne 18.4.2017 v 14:35 Tim Flink napsal(a):
> One of the things that seems like it is and will be a pain point for
> folks writing
On Tue, 2017-04-18 at 10:18 -0600, Kevin Fenzi wrote:
> On 04/18/2017 10:08 AM, Adam Williamson wrote:
>
> > One thought: we actually have the same problem for openQA, now it's
> > running tests on updates. This isn't very visible at present so devs
> > haven't been asking about it, but I suspect
On 04/18/2017 10:08 AM, Adam Williamson wrote:
> One thought: we actually have the same problem for openQA, now it's
> running tests on updates. This isn't very visible at present so devs
> haven't been asking about it, but I suspect as soon as the results show
> up in Bodhi, someone will be
On Tue, 2017-04-18 at 06:35 -0600, Tim Flink wrote:
> One of the things that seems like it is and will be a pain point for
> folks writing package-specific tasks is how to work through the times
> when there was an issue in the task and things didn't run well. At the
> moment, the only solution we
On Tue, 18 Apr 2017 14:53:07 +0200
Kamil Paral wrote:
> On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink wrote:
>
> > One of the things that seems like it is and will be a pain point for
> > folks writing package-specific tasks is how to work through the
> >
On Tue, Apr 18, 2017 at 2:35 PM, Tim Flink wrote:
> One of the things that seems like it is and will be a pain point for
> folks writing package-specific tasks is how to work through the times
> when there was an issue in the task and things didn't run well. At the
> moment,
One of the things that seems like it is and will be a pain point for
folks writing package-specific tasks is how to work through the times
when there was an issue in the task and things didn't run well. At the
moment, the only solution we have is to re-build the affected package
or to pester an