There was a reason to store VCS settings in ROOT project — minimising git polls which often caused 'too many connections' error, because each new VCS is separate instance even if it is the same as in the other project. Duplicating VCSs will reduce git performance.
Also — if we are going to have synced instances of TCs, it should be full sync with all settings and all projects. Otherwise — you have admin permissions that is more then enough to dump and restore pretty much any setting, except user database. > On 17 Dec 2021, at 16:43, Anton Vinogradov <a...@apache.org> wrote: > > Petr, > >> However, ROOT project will still be not under VCS and some major settings > like VCS roots, Clean-Up rules, custom step runners and so much more will > stay out of Git-based sync. > VCS roots are project-related and should not be stored somewhere outside > the project. > Also, having different roots at different TCs looks like a proper > configuration. > For example, TC2 may not contain the Ignite-3 project. > > On Fri, Dec 17, 2021 at 4:13 PM Petr Ivanov <mr.wei...@gmail.com> wrote: > >> Separate JIRA project will ruin the concept of introducing changes for >> both code and build settings in single branch of single project. >> >> >>> On 17 Dec 2021, at 15:14, Anton Vinogradov <a...@apache.org> wrote: >>> >>> Petr, >>> >>>> I strongly suggest avoiding a separate repository for project settings. >>>> Let's store them in https://github.com/apache/ignite >>> >>> Sounds good, but we must avoid dozens of additional commits in this case. >>> Each commit should be properly formalized and related to the issue. >>> We may create a special Jira project for CI issues to separate commits. >>> >>> On Fri, Dec 17, 2021 at 2:46 PM Pavel Tupitsyn <ptupit...@apache.org> >> wrote: >>> >>>> Petr, >>>> >>>>> why should I edit code in Apache Ignite 2.x repo to introduce new >> changes >>>> in Apache Ignite 3.x build settings >>>> >>>> I thought we can store 3.x settings in 3.x repo and so on. >>>> >>>> Looks like it does not work as I hoped it would. >>>> Thanks for your answers. >>>> >>>> On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov <mr.wei...@gmail.com> >> wrote: >>>> >>>>> Pavel, >>>>> >>>>> >>>>> If you are referring to this paragraph >>>>> >>>>> • If you are using TeamCity feature branches, you can define a >>>>> branch specification when creating a project from URL (Git only) or in >>>> the >>>>> VCS root used for versioned settings. TeamCity will run a build in a >>>> branch >>>>> using the settings from this branch. >>>>> >>>>> then it is only for new projects. >>>>> After setting current one all settings will be acquired from the chosen >>>>> branch and it will not be able to change (only create new project from >>>> new >>>>> branch). >>>>> >>>>> >>>>> And it still can be done from separate repository. >>>>> >>>>> >>>>> Choosing one of the project's repo to host settings for every other >>>>> project seems non-logical — why should I edit code in Apache Ignite 2.x >>>>> repo to introduce new changes in Apache Ignite 3.x build settings? >>>>> >>>>>> On 17 Dec 2021, at 14:28, Pavel Tupitsyn <ptupit...@apache.org> >> wrote: >>>>>> >>>>>> Petr, >>>>>> >>>>>>> you cannot run new suite added in branch because it just won't be >>>>> visible >>>>>> from UI >>>>>> >>>>>> That's unfortunate. >>>>>> However, a more important scenario is "make changes to the existing >>>>> project >>>>>> in a branch", which is supported, as I understand [1] >>>>>> >>>>>> [1] >>>>>> >>>>> >>>> >> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#Defining+Settings+to+Apply+to+Builds >>>>>> >>>>>> On Fri, Dec 17, 2021 at 2:19 PM Petr Ivanov <mr.wei...@gmail.com> >>>> wrote: >>>>>> >>>>>>> TeamCity DSL just does not work as you wish it should. >>>>>>> >>>>>>> >>>>>>> Changes from branches are not visible: you cannot run new suite added >>>> in >>>>>>> branch because it just won't be visible from UI because project UI is >>>>>>> rendered from default branch only), >>>>>>> and at least snapshot dependencies are taken from default branch >> only: >>>>>>> even if you will add dependency on already visible Run All >>>>> configuration, >>>>>>> it will be ignored. >>>>>>> >>>>>>> >>>>>>> Also about storing in already existing apache/ignite repository — >> that >>>>>>> will break the model about current separation on ignite and ignite-3, >>>>>>> ignite-extensions and so-on. >>>>>>> As we have different repositories for different parts of our project >>>> and >>>>>>> TeamCity unites them all — repository should be separate. >>>>>>> And when JB will fix the branches issues — we still will be able to >>>> use >>>>> it >>>>>>> with creating branches with the same name on both project and TC >>>>> repository. >>>>>>> >>>>>>>> On 17 Dec 2021, at 14:06, Pavel Tupitsyn <ptupit...@apache.org> >>>> wrote: >>>>>>>> >>>>>>>> Witaliy, >>>>>>>> >>>>>>>>> repository is created >>>>>>>>> only in the master branch >>>>>>>> >>>>>>>> I strongly suggest avoiding a separate repository for project >>>> settings. >>>>>>>> Let's store them in https://github.com/apache/ignite >>>>>>>> >>>>>>>> *1. We should be able to test code changes together with CI/CD >>>>> changes.* >>>>>>>> *2. We should be able to have different project settings in >> different >>>>>>>> branches.* >>>>>>>> >>>>>>>> For example, I may remove or rename a module in ignite/master branch >>>>> and >>>>>>>> update TC project accordingly, >>>>>>>> while it continues to work as before in ignite-2.12 branch where we >>>>>>> prepare >>>>>>>> the release with older code. >>>>>>>> >>>>>>>> This is super important and this is how most other projects do it >>>> (from >>>>>>> my >>>>>>>> experience). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Dec 17, 2021 at 11:12 AM Виталий Осилов < >>>>>>> osipov.wita...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Dear Ignite Community! >>>>>>>>> >>>>>>>>> I propose for discussion the conception of using two TeamCity >>>> servers >>>>>>> with >>>>>>>>> a roadmap. >>>>>>>>> https://ci.ignite.apache.org/ >>>>>>>>> https://ci2.ignite.apache.org/ >>>>>>>>> >>>>>>>>> Storing project settings. >>>>>>>>> Servers synchronize configurations between themselves using the >>>>> version >>>>>>>>> control-storing DSL (repository at https://github.com/apache). >>>>> TeamCity >>>>>>>>> allows to store the settings in the DSL based on the kotlin >>>> language. >>>>>>>>> You can read more about the version control-storing DSL here >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.jetbrains.com/help/teamcity/2021.2/kotlin-dsl.html#Getting+Started+with+Kotlin+DSL >>>>>>>>> This scheme will allow to maintain a single configuration for both >>>> TC >>>>>>> and >>>>>>>>> update configuration after a code review. >>>>>>>>> Changes in the suite should be made only in the master branch of >> the >>>>>>> stored >>>>>>>>> configuration. WebUI should be disabled on both TC. >>>>>>>>> The code-modified PR should be tested for compatibility before >>>>> approval. >>>>>>>>> >>>>>>>>> Configuring authentication. >>>>>>>>> It is proposed to switch sign in to TeamCity with using GitHub.com >>>>>>> account >>>>>>>>> ( >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> https://www.jetbrains.com/help/teamcity/configuring-authentication-settings.html#GitHub.com >>>>>>>>> ) >>>>>>>>> and restriction of access for the organization (https : // >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> docs.github.com/en/organizations/collaborating-with-groups-in-organizations/about-organizations >>>>>>>>> .) >>>>>>>>> User rights are changed on each server by request in Jira. >>>>>>>>> >>>>>>>>> Storing security credentials. >>>>>>>>> All credentials are stored on each server in the file >>>>>>> "<TEAMCITY_DATA_DIR> >>>>>>>>> / config / projects / <PROJECT_ID> >>>>> /pluginData/secure/credentials.json". >>>>>>>>> That is why it is supposed to configure the synchronization of this >>>>> file >>>>>>>>> between two servers. >>>>>>>>> >>>>>>>>> Maintenance. >>>>>>>>> All change requests of server's maintenance should be created in >>>> Jira >>>>>>>>> https://issues.apache.org/jira/projects/IGNITE >>>>>>>>> <https://issues.apache.org/jira/projects/IGNITE/summary> >>>>>>>>> Responsible for the servers and agents - TC1 Petr Ivanov and TC2 >>>>> Vitaly >>>>>>>>> Osipov. They are responsible for the health of the servers >> (backups, >>>>>>>>> updates, agents, etc.) >>>>>>>>> Both TC servers must be updated sequentially with a minimum time >>>>>>> interval >>>>>>>>> by request in Jira. >>>>>>>>> --- >>>>>>>>> At the first stage, it is required to synchronize the differences >> in >>>>>>>>> configurations. The configuration from TC1 is uploaded to TC2. >>>>>>>>> If changes are required in this configuration, tasks are created in >>>>>>> Jira to >>>>>>>>> change settings in TC1, then new configuration is re-uploaded to >>>> TC2. >>>>>>>>> Repository is created at https://github.com/apache. Tech-user is >>>>>>> created >>>>>>>>> for connecting to this repository. Tech-user should have RW access >>>> in >>>>>>> the >>>>>>>>> master branch. >>>>>>>>> Checking TC2 functionality for several weeks. >>>>>>>>> Stage 2 - The option of "synchronization of the project settings >>>> with >>>>>>> the >>>>>>>>> version control system" must be allowed for the root-project on >> TC1 >>>>> and >>>>>>>>> TC2. >>>>>>>>> The option "*Allow editing project settings via UI" must be allowed >>>>> on >>>>>>> TC1 >>>>>>>>> and disabled on TC2.* >>>>>>>>> Checking TC2 functionality for several weeks. >>>>>>>>> Stage 3 - Switch sign in to TeamCity with using GitHub with >> linking >>>>> TC >>>>>>>>> users to their accounts on the github.com. >>>>>>>>> Stage 4 - Configuring synchronization of secret files >>>>>>>>> "secure/credentials.json". Synchronization is one-way, so security >>>>> creds >>>>>>>>> can only be made on the TC1 server. Configuring upload and download >>>>>>> files >>>>>>>>> if they change. >>>>>>>>> Stage 5 - Setting up of checking PR before approval. >>>>>>>>> Stage 6 - Disabling the ability to edit configurations via WebUI on >>>>> TC1 >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>> >> >>
