Generate Teamcity config with kotlin dsl with multi-module setup
Hello folks,
I have a teamcity build that includes as build steps some complex python code that tries to verify some conditions, and based the inputs received (the details of a pull request) it defines some build parameters.
I'm trying to convert the project created with the UI to a versioned project that leverage the kotlin DSL feature.
In the export of the UI configuration to Kotlin DSL the python code (used as custom script in a build step) was extracted as huge text block in the kotlin code, however this basic approach is quite error prone, since it's easy to introduce errors in python code while editing a plain string (i.e. mixing spaces and tabs, or some typo), and those error would be identified only when the build is executed.
To avoid that I extracted the custom scripts into dedicated files so that I could also define some unit tests for them, and ensure that the script is ok before publishing new versions.
So at this moment my project looks like:
.
├── README.md
└── .teamcity
├── pom.xml
├── python_scripts
│ ├── python_identifier.py
│ └── test_python_identifier.py
├── README
├── settings.ktsThe issue I'm finding with this setup is that when I work in Idea I can't define multiple SDK for the same module, so while editing the python code I miss on all the IDE functionalities.
So I was trying to define python_scripts as a submodule, so I created the submodule definition .teamcity/python_scripts/pom.xml, but as soon as I add in .teamcity/pom.xml a section
<modules>
<module>python_scripts</module>
</modules>running the command mvn teamcity-configs:generate fails.
Is it feasible/supported what I'm trying to setup?
Is there a better way to organize the project so that the TC configuration are created correctly, and I'm also able to use the features of the IDE?
Thanks
Please sign in to leave a comment.
I see that you created a support request with the same question, and our engineers got back to you with a proposal to have Python scripts in a separate repository. This proposed approach has its advantages, but I want to add to it.
As I see it, there are three main components:
1. A source code to build (let's say `project` directory in a repository).
2. Python build scripts (`python_scripts` directory in a repository).
3. TeamCity Kotlin DSL project (`.teamcity`).
You can host them all in one repository or in separate repositories if you want to, all possible combinations have their own advantages and disadvantages. However, you should consider them as separate entities and don't make Python scripts a part/module of your TeamCity project.
Let's say, you would host all three components in one repository. This way, you can have changes in your TeamCity project and Python build scripts appropriate for the branches of `project`. Moreover, with this, you can implement running unit tests for your Python scripts as build steps in your TeamCity project before the build itself starts.
Or, if you're already using a separate VCS root for a TeamCity project, you can host Python scripts there, but in a separate directory, as a separate project, to have access to all IDE functionality, etc. The Python build step itself just runs the script from a Python file (but you would need to attach this VCS root to build configuration in this case).
Please let me know if you have any concerns with any of the above options. However, generally speaking, I recommend thinking about build scripts as either a part of the project itself, or separate from it, but not as a part of the TeamCity project (as you correctly noticed, TeamCity handles the scripts inside a build step as plain text, which won't let you use IDE features, which may be OK for small scripts, but isn't convenient for complicated ones).
Best regards,
Anton