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
>>>>
>>
>>
