> It makes sense to me that release runs the the tests on the artifacts,
Me too as long as they don't increase the release time too much.
If we move those tests to ci.jenkins.io, it becomes more monitoring as we'll
run tests on public artifacts and so it will make more sense to use Datadog to
Hi all,
Olivier: While we agreed to switch weekly versions to the new release
> environment, we didn't clarify who should be responsible for those weekly
> releases and when we trigger them.
Mark: I think you're proposing a "build master" role for the weekly build.
> That role would
On Fri, Apr 24, 2020 at 3:21 PM Tim Jacomb wrote:
> Couldn’t multiple instances run it?
>
Yes, multiple instances could run it
> It makes sense to me that release runs the the tests on the artifacts,
>
The plan is that the package step will run tests on the packaged
components. There are
Couldn’t multiple instances run it?
It makes sense to me that release runs the the tests on the artifacts,
And also makes sense that ci.jenkins.io has tests that it’s working
(possibly it could have simpler tests and doesn’t need to run the full
acceptance tests set)
Thanks
Tim
On Fri, 24 Apr
On Fri, Apr 24, 2020 at 12:52 PM Jesse Glick wrote:
> On Fri, Apr 24, 2020 at 12:19 PM Mark Waite
> wrote:
> > The test results aggregator plugin might help us combine test results
> from multiple jobs into a single summary job.
>
> Or just combine them into one job.
>
>
That is certainly an
On Fri, Apr 24, 2020 at 12:19 PM Mark Waite wrote:
> The test results aggregator plugin might help us combine test results from
> multiple jobs into a single summary job.
Or just combine them into one job.
--
You received this message because you are subscribed to the Google Groups
"Jenkins
On Fri, Apr 24, 2020 at 9:12 AM Olblak wrote:
> Hi,
>
> While we agreed to switch weekly versions to the new release environment,
> we didn't clarify who should be responsible for those weekly releases and
> when we trigger them.
> As long as the process is not 100% stabilized I think it makes
