ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Pavlov <dpavlov....@gmail.com>
Subject Re: TeamCity triggers change proposal
Date Mon, 19 Jun 2017 12:22:14 GMT
Hi Semyon,

As far as I know, build Priorities (Build Priority classes) may be created
and configured only in relation to specific run (build) configuration, but
not in relation to trigger (cause this build was started). Second option
which may provide prioritization is agent pools, but still run
configuration can be assigned to the pool, but not trigger type.

I’ve got one question too: it is often that results of VCS-triggered build
are expected to be completed same day? Is this case often, that someone is
continuously checking and waiting results of VCS triggered build?

Any comments welcome.

Best Regards,
Dmitry Pavlov


пн, 19 июн. 2017 г. в 14:50, Semyon Boikov <sboikov@gridgain.com>:

> Hi Dmitry,
>
> Is it possible instead to set priority for manually started builds higher
> than for builds triggered by git?
>
> Thanks
>
> On Fri, Jun 16, 2017 at 2:37 PM, Dmitry Pavlov <dpavlov.spb@gmail.com>
> wrote:
>
> > Hi Igniters,
> >
> >
> >
> > Most of us at least once have faced with situation that we have important
> > fix to be tested, but TeamCity is busy and queue is too long. Ignite 2.0
> > test introduction helped to reduce time to wait, but still there is
> > potential to get results for your PR tests faster.
> >
> >
> >
> > Contribution itself is tested under PR and TC ‘Run All’ started manually.
> > Second test will be performed later: all test suites will be started for
> > after merge into master (ignite 2.0).
> >
> >
> >
> > I offer to change VSC trigger to schedule trigger for master and 2.0
> > branches. Schedule trigger will be launched daily at period of low
> activity
> > (TC queue is empty), for example at 2am GMT.
> >
> >
> >
> > This solution help to get results faster for each PR. Solution still
> > protects master from merge problems. If master tests are required due to
> > high risk, committer will be still able run start RunAll For master.
> >
> >
> >
> > Any thoughts or comments? I would like apply this change by the end of
> next
> > week.
> >
> >
> >
> > Sincerely,
> >
> > Dmitriy Pavlov
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message