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