Regarding security - we should make sure that we don't run scripts changed in PRs from external contributors. If a non-committer changes a TC script in their fork, then we should not start a TC build automatically.
I think this can be done in GitHub with workflow approvals. On Fri, Dec 20, 2024 at 3:37 PM Pavel Tupitsyn <ptupit...@apache.org> wrote: > Mikhail, thank you for taking the initiative. > > I agree with the Kotlin DSL direction. > > > slowdown in indexing in the developers' projects > > IDEA can exclude a folder from indexing [1] - should be an easy workaround. > > [1] https://www.jetbrains.com/help/idea/indexing.html > > On Fri, Dec 20, 2024 at 2:22 PM Mikhail Pochatkin <m.a.pochat...@gmail.com> > wrote: > >> I fully support the proposal regarding the transition to the code base >> approach. As Peter said, we may have problems with testing the build from >> branches, but as far as I see in the TC documentation [1] it is stated >> that >> this is a fully working feature, if we encounter bugs, then this is not an >> blocker. >> > If the changes are applied on the VCS side (if a Kotlin or XML settings >> file is edited), the TeamCity server detects them and modifies the project >> on the fly. >> >> I can be the driver of this activity and make a plan for the transition >> to >> Kotlin DSL scripts. The only thing that may be controversial is adding >> Kotlin to the dependency, which can lead to some slowdown in indexing in >> the developers' projects, but this can also be tried to bypass by locally >> excluding folders with scripts in IDE. >> >> >> [1] >> >> https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html#SynchronizingSettingswithVCS >> >
