I have a build chain of 4 build configurations, which correspond to different teams' tasks. The idea behind the configurations is this:
Run the build itself
Move build to staging
QA approved
Release
Each of those configurations have different responsible people. People not responsible for a given configuration should not be allowed to run it.
I know I can define roles on project-level, but here I need to define it on a build configuration-level. Is that possible?
Thanks
You can create subprojects for each configuration and then assign roles corresponding to restrictions.
You can add precondition step to each job where check username and fail step and job if user not allowed to run this job.
I made the second approach in similar case.
Related
Similar to this question, I want to run multiple Run Configurations as one. However, instead of running them simultaneously (parallel), I want to run them after one another in a specific order.
I know I can select another Run Configuration to run before another, like answered here, but approach has one issue: it's not possible to have one generic/main/super Run Configuration that runs nothing else than the specified run configurations. I must to pick one project-specific configuration (e.g. a Python configuration in PyCharm, the JetBrains Python IDE similar to IntelliJ IDEA) to be able to choose Run Configurations to run serially before the main one. This is an issue, because if I ever want to change to or insert a different configuration where the main Python Run Configuration is, I need to remake the Run Configuration Order besides a new one. With a predefined serial list of Run Configurations to execute, this would be as simple as inserting another configuration in the list.
Is this possible and how do I achieve this?
Besides the Before launch functionality mentioned in the question, there is no such possibility in IntelliJ IDEA and other JetBrains IDEs to my knowledge. However, there exists plugins that add Run Configurations that initially do nothing (empty), which can be considered as a generic/main/super Run Configuration. In such a configuration the regular way of specifying other configurations to run sequentially before launch can be used to achieve the question's goal.
An example of a plugin that adds an initially empty Run Configuration is the Multirun plugin. Don't be confused by its name: it's meant to run multiple Run Configurations simultaneously with the option to start them sequentially, but it does not wait for earlier ones to finish before starting the later ones. Just add the default (empty) Multirun configuration and queue up other tasks to run sequentially through the Before launch section.
It's a pity JetBrains haven't added a serial/sequential execution configuration in their Compound Run Configuration, which basically achieves what the Multirun plugin achieves: simultaneous / parallel execution. With compound run configurations, the Run Configuration editor would become a really powerful but simple to program configurations for various wishes like Gradle achieves for more complex build configurations.
The Gitlab documentation says the following about GIT_STRATEGY: none:
none also re-uses the project workspace, but skips all Git operations (including GitLab Runner's pre-clone script, if present). It is mostly useful for jobs that operate exclusively on artifacts (e.g., deploy). Git repository data may be present, but it is certain to be out of date, so you should only rely on files brought into the project workspace from cache or artifacts.
I'm still a bit confused about how this is supposed to work. If the source code is not guaranteed to exist, then there might be no source in the project workspace and thus the .gitlab-ci.yml file would also be missing. Without a build script the job must fail. If the source is missing only part of the time depending on external factors, the job will fail randomly, which is even worse than failing every time. However, if it fails every single time then what's the point of the feature?
Another possibility I see is that .gitlab-ci.yml might be injected at runtime, so that even without a fresh copy of the repository there would be a build script. If so, could I define further files from my repository to inject into the build process? What are the restrictions on these particular jobs?
Yes, the .gitlab-ci.yml file is not copied onto the system just like all the other files. But that doesn't matter as the job is not run from the file. The job is run as a script on your target (and even before that as it defines the target it will run on). It is not possible to copy only selected files without a git clone although you may want to copy the files from some other server.
A good example of when you want to run GIT_STRATEGY: none are things like slackchat notifications as last stage of a build when you really don't want to clone gigabytes of repository data just to push a notification.
TLDR: How can I arrange it so that a snapshot dependency does not trigger new builds?
For my test processes to run, they need to run on a "Test" environment. Creating such an environment is simple, but lengthy; it can take as much as 45 minutes to an hour to finish building a test environment. Further, the name of the environment, and other such variables, is not fixed until the environment has finished building.
In my TeamCity build definition, I could put "build environment if missing" as a build step. However, that means that the first test of the day will take 45 minutes to run.
Instead, we created a separate build, that is scheduled to run every morning, that builds the test environment for the day. Our test build then has a snapshot dependency to that build in order to use the parameters of that build to determine the environment information, and everything works as expected, except for one issue:
When a new test is run, it frequently seems to trigger a rebuild of the test environment creation.
We don't want this to ever happen; the test environment creation is 'done' for the day and should not need to run again until tomorrow. How can we achieve this?
You already have time based trigger => environment will be prepared every morning
Create Snapshot Dependency in your product TC configuration (not in that one which is preparing test environment) and tick 'Do not run new build if there is a suitable one'
Your configuration used to setup test environment should not have any VCS root (or point to some calm place of source control where submits will not happen). To physical setup your environment you should not need any source code mapping etc. - you may consume everything needed through your own NuGet packages for example.
Note: In this workflow every build of your real project will enlist build of configuration which sets test environment (so it's physically in build queue) but
when it's turn come up it will compare changes since last build => no submits on VCS found (it's pointing to calm place in SourceControl due step 3)) and so build will be skipped in <1s
I am new to teamcity and need some help in setting up the parameterized build.We are using jenkins to run regression project written in SoapUI and through paramiterized build options we are able to pass parameter(such as test environment,mercurial banch it has to pool the changes from, test suites in case we have executes only selected ones and tags) to the batch script that executes the testrunnner.bat on command line. How can I do the same stuff in teamcity?
I can see teamcity allows three types of parameters env,system and config.Out of which system parameters are passed to the build script.Can I specify all these required parameters as system parameter?
Also I need to supply these parameters for every build but the values may differ.Does teamcity provides facility same as jenkins that would provide a GUI where I can change these values?
Yes, you can use system properties for required parameters that should be passed inside build script.
To specify what mercurial branches to monitor you can configure Feature Branches.
You can run a build manually in TeamCity and customize needed parameters, see how to Trigger Custom Build.
I have a project that need to be deployed into multiple environments (prod, test, dev). The main differences mainly consist in configuration properties/files.
My idea was to use profiles and overlays to copy/configure the specialized output. But I'm stuck into if I have to generate multiple artifacts with specialized classifiers (ex: "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") or should I create multiple projects, one project for every environment ?!
Should I use maven-assembly-plugin to generate multiple artifacts for every environment ?
Anyway, I'll need to generate all them at once so it seams that the profiles does not fit ... still puzzled :(
Any hints/examples/links will be more than welcomed.
As a side issue, I'm also wondering how to achieve this in a CI Hudson/Bamboo to generate and deploy these generated artifacts for all the environments, to their proper servers (ex: using SCP Hudson plugin) ?
I prefer to package configuration files separately from the application. This allows you to run the EXACT same application and supply the configuration at run time. It also allows you to generate configuration files after the fact for an environment you didn't know you would need at build time. e.g. CERT
I use the "assembly" tool to zip up each domain's config files into named files.
I would use the version element (like 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) and thus tags/branches at the VCS level in combination with profiles (for environments specific things like machines names, user name passwords, etc), to build the various artifacts.
We implemented a m2 plugin to build the final .properties using the following approach:
The common, environment-unaware settings are read from common.properties.
The specific, environment-aware settings are read from dev.properties, test.properties or production.properties, thus overriding default values if necessary.
The final .properties files is written to disk with the Properties instance after reading the files in given order.
Such .properties file is what gets bundled depending on the target environment.
We use profiles to achieve that, but we only have the default profile - which we call "development" profile, and has configuration files on it, and we have a "release" profile, where we don't include the configuration files (so they can be properly configured when the application is installed).
I would use profiles to do it, and I would append the profile in the artifact name if you need to deploy it. I think it is somewhat similar to what Pascal had suggested, only that you will be using profiles and not versions.
PS: Another reason why we have dev/ release profiles only, is that whenever we send something for UAT or PROD, it has been released, so if there is a bug we can track down what the state of the code was when the application was released - it is easier to tag it in SVN than trying to find its state from the commit history.
I had this exact scenario last summer.
I ended up using profiles for each higher environment with classifiers. Default profile was "do no harm" development build. I had a DEV, INT, UAT, QA, and PROD profile.
I ended up defining multiple jobs within Hudson to generate the region specific artifacts.
The one thing I would have done differently was to architect the projects a bit differently so that the region specific build was outside of the modularized main project. That was it would simply pull in the lastest artifacts for each specific build rather than rebuild the entire project for each region.
In fact, when I setup the jobs, the QA and PROD jobs were always setup to build off of a tag. Clearly this is something that you would tailor to your specific workplace rules on deployment.
Try using https://github.com/khmarbaise/multienv-maven-plugin to create one main WAR and one configuration JAR for each environment.