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