[MTCGA]: new failures in builds [6138457] needs to be handled

2021-08-17 Thread dpavlov . tasks
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Cache (Restarts) 1 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E No changes in the build

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Ivan Daschinsky
>> Btw, I was always against moving thin clients into separate repos. Monorepo Monorepo is a mostly cargo cult. What is suitable for google is not suitable for others. For example, we have already released new versions of pyignite with many new features. When this client was in our super repo, it

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Pavel Tupitsyn
Ivan, 1. It will be clean. It will actually be better: good to know when build failure is caused by a config change, right? 2. Can you please provide an example in a well-known open-source project other than Ignite? Btw, I was always against moving thin clients into separate repos. Monorepo

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Ivan Daschinsky
1. Clean commit history (As one developer said, git history is an api) 2. We have separate thin client repos -- but TC thin client build depends on ignite build also. вт, 17 авг. 2021 г. в 18:08, Pavel Tupitsyn : > Ivan, > > > I'm sorry, but what about storing TC configs in separate repo? >

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Pavel Tupitsyn
Ivan, > I'm sorry, but what about storing TC configs in separate repo? What are the pros of this approach? What do we gain? Separate repo always adds friction, and it is not clear how to handle config changes that are tied to code changes. > It is quite common approach. Can you provide an

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Ivan Daschinsky
I'm sorry, but what about storing TC configs in separate repo? It is quite common approach. вт, 17 авг. 2021 г. в 17:33, Pavel Tupitsyn : > Anton, > > > This will kill repo history. > > You'll see dozens of TC config updates vs a single Ignite fix > > Not really. > I'm not suggesting something

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Pavel Tupitsyn
Anton, > This will kill repo history. > You'll see dozens of TC config updates vs a single Ignite fix Not really. I'm not suggesting something crazy, this is the modern way to do CI/CD - see GitHub actions, Azure pipelines, etc - you write a config and store it in Git. > Where are you going to

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Petr Ivanov
After initial setup, there won't be lot's of changes, at least for PRs there will be single commit with both fix and TC changes. > On 17 Aug 2021, at 13:05, Anton Vinogradov wrote: > > This will kill repo history. > You'll see dozens of TC config updates vs a single Ignite fix

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Petr Ivanov
Unfortunately, it won't work. At least in the nearest future. Currently, you cannot see project structure on TC in any branch except default (master/main). And some things like snapshot dependencies are ONLY taken from default branch. > On 17 Aug 2021, at 10:25, Pavel Tupitsyn wrote: > >

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Anton Vinogradov
> I think TC config should be stored in the same repo as the corresponding > code (2.x config in 2.x repo, 3.x in 3.x, etc). This will kill repo history. You'll see dozens of TC config updates vs a single Ignite fix > it would be great to be able to test them by simply creating a new branch > in

Re: Storing Teamcity projects settings in Version Control

2021-08-17 Thread Pavel Tupitsyn
Dmitry, Petr, I think TC config should be stored in the same repo as the corresponding code (2.x config in 2.x repo, 3.x in 3.x, etc). Changes and updates to build scripts and project structure often come together with changes to TC configuration, it would be great to be able to test them by