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