Awesome job!
On 3 May 2018 at 14:04, Guillaume Smet wrote:
> On Thu, May 3, 2018 at 2:47 PM, Guillaume Smet
> wrote:
>>
>> On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero
>> wrote:
>>>
>>> Very cool!
>>>
>>> Feel free to build it and deploy on ci.hibernate.org ?
>>
>>
>> I deployed it on ci.hib
On Thu, May 3, 2018 at 2:47 PM, Guillaume Smet
wrote:
> On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero
> wrote:
>
>> Very cool!
>>
>> Feel free to build it and deploy on ci.hibernate.org ?
>>
>
> I deployed it on ci.hibernate.org just now.
>
> It would be nice if you could check which jobs get
On Thu, May 3, 2018 at 1:17 PM, Sanne Grinovero wrote:
> Very cool!
>
> Feel free to build it and deploy on ci.hibernate.org ?
>
I deployed it on ci.hibernate.org just now.
It would be nice if you could check which jobs get triggered when you push
something to master/a specific branch.
--
Gui
Very cool!
Feel free to build it and deploy on ci.hibernate.org ?
On 3 May 2018 at 11:53, Guillaume Smet wrote:
> On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet
> wrote:
>
>> So I would say:
>> - either we fix the issue we have with all the branches being tested for
>> each commit that we disc
Great! Thanks a lot :)
I added a few comments, but nothing very important.
On Thu, 3 May 2018 at 12:55 Guillaume Smet wrote:
> On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet
> wrote:
>
> > So I would say:
> > - either we fix the issue we have with all the branches being tested for
> > each c
On Mon, Apr 30, 2018 at 6:09 PM, Guillaume Smet
wrote:
> So I would say:
> - either we fix the issue we have with all the branches being tested for
> each commit that we discussed numerous times
>
Here it is:
https://github.com/gsmet/github-plugin/commit/03328fcf8ecd9117d1c8c2a9b967efa111d6be46
Let's keep in mind that the current way CI works is the only way we can
enable starting nodes on-demand. Any solution involving the "heavy job"
plugin like we used to will force us to have a static number of nodes, and
leave them up even when unused for extended periods of time, leading us to
eithe
Using docker might be a nice idea if the machines are powerful enough.
I will just mention it here but for the release only we can also not
use Jenkins and run the command
we need from the terminal of ci.hibernate.org. We already have the
scripts ready so it shouldn't be too hard.
If the Jenkins
On Mon, Apr 30, 2018 at 8:34 PM, Sanne Grinovero
wrote:
> Starting a new slave only takes 3 minutes, but I believe it has to be
> a "manual start" from its admin dashboard as Jenkins's scaling plugin
> is limited.
>
> Fixing the Jenkins triggers would be my preference.
>
Yeah, last time we discu
Starting a new slave only takes 3 minutes, but I believe it has to be
a "manual start" from its admin dashboard as Jenkins's scaling plugin
is limited.
Fixing the Jenkins triggers would be my preference.
Alternatively:
- we could look at pipelines
- run all jobs within Docker -> improved isolat
Then we should move to a CI server that is not erroneously triggering jobs
it should not.
On Mon, Apr 30, 2018 at 11:30 AM Guillaume Smet
wrote:
> Hi,
>
> So, as expected, I'm not very happy with the new CI setup when doing
> releases.
>
> The issue is that each commit to ORM triggers at least 5
Hi,
So, as expected, I'm not very happy with the new CI setup when doing
releases.
The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1,
5,2, master-h2, master-check) which takes all the slave bandwidth we have.
Note that I'm talking of ORM because it's where the issue is the
12 matches
Mail list logo
