Skip to content

TeamCity: port build configs to in-repo Kotlin DSL#178

Open
sergej-koscejev wants to merge 1 commit into
v1.xfrom
teamcity/kotlin-dsl-v1.x
Open

TeamCity: port build configs to in-repo Kotlin DSL#178
sergej-koscejev wants to merge 1 commit into
v1.xfrom
teamcity/kotlin-dsl-v1.x

Conversation

@sergej-koscejev

Copy link
Copy Markdown
Member

Summary

  • Moves the mps-gradle-plugin and git-based-versioning TeamCity build configurations from the TC UI into .teamcity/settings.kts (Kotlin DSL).
  • Keeps full parity with the current v1.x behavior: the plugin build runs setTeamCityBuildNumber build and then publish; git-based-versioning runs :git-based-versioning:build :git-based-versioning:publish.
  • Pom layout mirrors mbeddr/publish-mps-prereleases/.teamcity/pom.xml — parent org.jetbrains.teamcity:configs-dsl-kotlin-parent:1.0-SNAPSHOT via https://mps.builds.itemis.cloud/app/dsl-plugins-repository.
  • Pairs with the master PR (same change, without the Publish step) so master can later diverge for 3.0.0: task-type interfaces, Gradle 9, drop legacy plugins #177 (selective on-demand publishing of included builds) without touching v1.x.

Handover checklist for TeamCity

These steps apply once both this PR and the master PR are merged:

  1. On the newly-created Mbeddr_Tooling_MpsGradlePlugin subproject in TeamCity, switch Versioned Settings synchronizationMode from useParentProjectSettings to Synchronization enabled. Point at the existing VCS root (Mbeddr_Tooling_MpsGradlePlugin, which targets https://github.com/mbeddr/mps-gradle-plugin). Turn on "Use settings from the branch being built".
  2. TC imports the DSL; two new build configs appear. Trigger each manually on v1.x and master and compare against the last legacy runs (build log, ##teamcity[buildNumber '…'], artifact list, GitHub commit status).
  3. After parity, archive or delete the two legacy configs (Mbeddr2_Mbeddr_Gradle_MpsGradlePlugin, Mbeddr2_Mbeddr_Gradle_GitBasedVersioning).

Note: the DSL reuses the inherited %system.github.token% for the commit-status publisher. Worth confirming this is the same token the current legacy config's per-build-config secure:github_access_token holds; if not, we'll need a project-scoped credentials entry before archiving the old config.

Test plan

  • cd .teamcity && mvn teamcity-configs:generate produces XML under target/generated-configs/ matching the live configs' semantics.
  • After TC sync on v1.x, plugin build runs Build + Publish, publishes a maven-mps-snapshots artifact, GitHub commit status updates.
  • After TC sync on v1.x, git-based-versioning build runs its single step successfully (triggered manually or via dependency).
  • No "settings differ from VCS" warnings on the new project after first sync.

🤖 Generated with Claude Code

Moves the mps-gradle-plugin and git-based-versioning build
configurations from the TeamCity UI into .teamcity/settings.kts, so the
build of this branch can evolve in lockstep with its code.

The pom.xml matches the layout used by mbeddr/publish-mps-prereleases;
`mvn teamcity-configs:generate` resolves against
https://mps.builds.itemis.cloud/app/dsl-plugins-repository and produces
XML that matches the current UI-managed configs semantically.

Applying this on the server requires the new `Mbeddr_Tooling_MpsGradlePlugin`
subproject to switch its versioned-settings mode from
`useParentProjectSettings` to "Synchronization enabled" against the
existing VCS root, with "Use settings from the branch being built"
turned on.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

@nkoester nkoester left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reviewed the changes in this PR. Sergej and I had a call on March 23rd to discuss the context, and we've covered all the $3.0$-related updates. Thanks for your work! LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants