The workspace in diagram below flows to a stream.
I've added a build definition which builds from this workspace.
If I deliver change sets from a different workspace to the stream in diagram should these change sets be built when I perform a build ? Do the change sets need to be first accepted into the workspace from the stream before they are built ?
Currently when I perform a build the change sets(which have been delivered to the stream from a different workspace)
are not being delivered to the workspace in diagram and so are not being built.
If I deliver change sets from a different workspace to the stream in diagram should these change sets be built when I perform a build?
Do the change sets need to be first accepted into the workspace from the stream before they are built?
It depends how your build definition is configured:
As this thread mentions:
If you are using a build definition that has 'Jazz Source Control' selected as a pre-build participant, you will see in the bottom section of the 'Jazz Source Control' tab the 'Accept Options section'.
The 'Accept latest changes before loading' checkbox should be checked for you to automatically accept changes.
But with a BuildForge-based Build Definition, as mentioned in "Rational Team Concert 3.0 and Build Forge: An integration scenario":
[...] Once a Server is selected, as first Step, the Build Forge project loads an Adaptor (JazzJBE.xml) to facilitate the integration between Build Forge and RTC.
This adaptor runs the Jazz Build Engine, which is part of the buildtoolkit, to accept and fetch source code based on the properties passed on by the RTC Build Definition
(A more typical continuous integration scenario with RTC would have the Jazz Build Engine running in the background on the build Server, listening for requests. With the JazzJBE adaptor, the Jazz Build Engine is launched on demand).
Related
I would like to be able to publish from visual studio. I am able to do this
I have different configurations for Debug,QA,Release. I am using config transforms and they work fine.
ISSUE: when I publish the I want the Debug, QA,Release to be published to their respective folder example E:\Application\Debug and so on. I am able to do this by changing the Publishing folder location and Installation folder location manually. How can this be such: f I change the configuration these locations are selected automatically. So when I need to publish a particular version -> and all I need to do is
change the config
press the publish now button.
Thanks!
The only possibility I know of would be to use a Build Server and build if the Source code changes (probably seperate branches) and have build definitions for each case.
This would mean that you would have to have a kind of source control (Git, Mercurial, TFS) for the Project and the resources to run that kind of service or use a Service on the internet.
Build Server for local installation:
TeamCity
Team Foundation Server
Build Server via Internet:
VisualStudio.com
(Those are the onse that come to my mind because I have used them before. There are much more available)
I would like to disable/enable Build Controller (or Build Agents) from a bat file. I want to do this so we can schedule builds every night, but then disable them during code-freeze. "TFPT builddefinition /enabled:false" is close... but that is only for cloning build defs. If not, is there a way to disable checkins from a bat file? Then I would edit my Build Def and uncheck the box for "Build even if nothing has changed since the previous build".
Thanks
You can create a Rest call to the private and undocumented TFS API, but you should know what you are doing.
Or you can use a scheduled tasks to control your agent service installation on your build server.
But there are better ways to control your sources and releases.
It seems like the problem is your TFS project setup. For example, use
"GIT Hub Flow" with “Pull Requests” and no one can change the master
without a approved PR.
The developers can he developers can work and you don’t need plan a
“Code Freezes" or "removing permissions" or stuff like this.
I also wouldn´t stop the deployments for the dev and test systems.
If you want to avoid that anybody creates a release to a special set of environment (Stag and Prod) set an approvers to control the release process.
The understanding Git-Hub-Flow site
"GitHub Flow is a lightweight, branch-based workflow that supports
teams and projects where deployments are made regularly." GIT Hub
https://guides.github.com/introduction/flow/
A recent question in the Codename One discussion forum raised a question I often face when I'm waiting for a fix.
Sometimes the Codename One team indicates a fix would be coming in a couple of weeks and other times they indicate that its already fixed. Some of that opacity obviously relates to the update of the cloud servers but its unclear for me whether its just the cloud server & the plugin or is there something that I'm missing. Why isn't there a single update process?
I'd really like a more definitive answer like How does Codename One work?
for this.
Codename One is comprised of several different pieces and an update usually means we update only one of them. At a high level there are really just 2 major types of updates: libraries & servers.
We update libraries once every 3-5 weeks we update servers all the time (sometimes more than once per day sometimes ever 3-4 days).
Here is a slightly more accurate overview of what it means to update Codename One:
Plugin & related tools - the plugin itself provides the project properties, server connectivity and designer/gui builder tools. It updates as part of the native IDE update process once every 3-5 weeks. You need to explicitly accept an update prompt from the IDE in order to get this update. Bugs in the plugin itself or features for the designer/GUI builder need to go thru that process...
Build.xml - this is technically a part of the plugin update but you need to actually accept changes that we make to the build.xml to get some functionality. On occasion a new feature (e.g. the new GUI builder) needs to update the build.xml code but this will only happen if you go into project properties, click OK and accept the prompt to update the build.xml (if such an update exists).
Client libraries - these are the API's you use when writing Codename One code (typically CodenameOne.jar and related ports). We usually issue an update to those once every 3-5 weeks together with the plugin update. The plugin ships with these but they are only applied to new projects... When you send a build we implicitly update your libraries to the latest version using a separate update process, you can also use "Update Client Libs" within the Codename One preference to update these manually without sending a build.
Device libraries - when you send a build to the servers we use the latest version of the client libraries that might be newer than what you see in the client libs but might not be the latest git master. This allows us to rapidly deploy & test device fixes. This also allows you to work with the code and use newer features that weren't pushed to the Client Libraries. The process of updating the servers is a bit adhoc so there is some opacity around that, we are looking at making this more transparent.
VM & builders - The builder code and VM relate to the server side scripts that generate the code. When you have a compilation error on the servers or need an enhancement there we need to deploy it in a process similar to the device libraries deployment.
Certificate wizard update - this tool is updated in a completely separate update process despite shipping in the plugin. We had a lot of concerns about Apple changing things suddenly when initially creating this so we decided to allow this to update instantly.
We are currently building a WPF application which is to be deployed via Click Once, the build is currently being handled by a Team City server.
We are noticing that every time someone checks in some code and the CI server builds the deployment package, the “Application Files” directory contains an additional version of the application.
Due to the mounting size of Click Once deployment, this is becoming un-scalable, does anyone have any idea how to limit the number of previous versions that are placed inside the Application Files directory?
The application files directory:
Click Once does not provide any mechanism for handling the published deployments. It would be difficult for Microsoft to do that, because everybody's requirements would be different. I'm sure that's why Team City didn't add that ability either (assuming they didn't, I don't use Team City).
I'm using TeamCity 6.5.4 and I need to have 3 build configurations for the same deployment package. I'd like to persist the version number across all three build configurations and be able to use that number to version the assembly, tag vcs, version the nuspec file, etc.
Here are the configurations and desired version numbers:
Configuration | Version
-------------------|---------
CI/Nightly Build | 1.1.*
Minor Release | 1.*.0
Major Release | *.0.0
It seems that TeamCity uses a separate build incrementer for each configuration. This means every time we have a major or minor release, I'd have to manually update the persisted values (1) in all of the subsequent configurations. I'm a programmer and I'm lazy. I want a single button to do everything for me.
I've seen examples of persisting the build number through build steps of a configuration with dependent snapshots, but that only works in the same configuration.
The Autoincrementer plugin bumps up the number every time you reference the ID. This is fine for the changing numbers (*), but not so good for referencing the persisted values (1).
Is there a way for TeamCity, either natively or via plugin, to allow me to read and write that version to a file or variable that can be persisted across build configurations?
You can reference the build number of the dependent ( artifact / snapshot) configuration using dep.btx.build.number where btx is the bt id of the latter. Once you have the build number, pass the build number to your script running in the configuration, parse the build number in the script and send service messages from the script to Teamcity to set the build number in the way you want. Do this parsing and setting number as the first step in your script / first step in the build steps.
Thanks for the suggestions. I opted to write a set of custom targets to use with my MSBuild script which maintains assembly metadata in a remote xml "manifest" file. When a new TeamCity project is created, my build script calls an Init target which creates a new manifest file from an unpopulated template.
<Copy SourceFiles="#(ManifestTemplate)" DestinationFiles="#(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" />
I'm using the MSBuild Extentions pack to read attributes like version information from the manifest file.
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="ReadElementText" File="$(ManifestFile)" XPath="/Package/Version/Major">
<Output PropertyName="PackageVersionMajor" TaskParameter="Value"/>
</MSBuild.ExtensionPack.Xml.XmlFile>
I have my TeamCity build configurations separated to CI, Test, Minor Release, and Major Release with different events triggering each. From the corresponding target in my project build script, I add a new target to DependsOnTargets attribute to call the custom target to update the appropriate version number and save it to the manifest file.
<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build">
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" />
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" />
The code in the custom target to handle the version update:
<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1">
<Output PropertyName="PackageVersionBuild" TaskParameter="Result"/>
</MSBuild.ExtensionPack.Science.Maths>
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/>
This file handles persistence of the version and other metadata thus ignoring the TeamCity build number. Since the XML metadata file is centralized, I can use the values to populate my Nuspec, AssemblyInfo, and WiX Installer metadata as well as pass the version and other pertinent information back to TeamCity through service messages.
I added a simple MVC web interface to allow my team to edit the file contents remotely if package details change. Now we have one single place to update things like Copyright information and any other metadata for a given build project. I can also give non-dev folks access to the MVC site to update branding information without allowing them access to my TeamCity build configurations.
With the exception of the service messages used to relay version to TeamCity, there's very little here that's coupled with TeamCity. I like having the functionality in custom targets and build scripts removed from TeamCity on the off chance we move to another build management solution. For that reason, I don't envision taking time to build a TeamCity plugin, but there could be a blog series coming soon.
I'll be happy to provide more code and further explanation to anyone interested.
Yes, you can create a plugin to do this easy. You can take my auto increment build number ( across configurations ) plugin and modify it to fit your need. The build number will be saved in a text file that is configurable from the admin screen in TeamCity.
http://github.com/ornatwork/tc_plugins/tree/master/unique
You can hit me up for input how to change it if you need.