We CAN store build settings per project — ignite, ignite-3, ignite-extensions and so on. 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. And in order to achieve full settings sync we should store root project with all subprojects.
Yet, there is a trade-off variant, where we can store ROOT settings in separate repo (let's call it ignite-tc) and under it set each project to inherit settings from there own repositories. We can start with all settings, extracting and moving project by project into theirs respectful repositories. > On 17 Dec 2021, at 14:46, 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 >>>>>> >>>> >>>> >> >>
