Something has managed to break on my TFS build. Whenever my deployment build is selected to a specific build, it shows the possible configurations (in my case dev1, dev2, test1, test2 and prd). However when I select <Latest> it disables the possible configurations. My deployment relies on this so it fails.
Where does TFS get these configurations for <Latest>? I'd have thought from the latest successful build. But this does have configurations when I select that specific build.
Any tips?
According to your information, guess you are using release management for the deployment.
If you select <Latest>, release management will catch the latest successful build of the build definition. It will ignored the failed build. Just as you guessed.
If you select <specific build>, then it will list the all successful build result of the build definition.
Related
I have to create CI/CD pipeline in TFS 2017 to execute JMeter performance test.
I've created a build definition according to the tutorial and a release definition (I have used created build definition as an artifact for the release definition).
After trying to create new release I get the following message: Versions could not be loaded for all artifact sources. This could be due to inaccessible artifact source or artifact source has been deleted or no versions are available.
Could someone help to fix it? Thank you in advance 😊
The error you are getting because it couldn’t access the artifact source anymore due to some reason.
May like there are not available builds (deleted by retention policy)
or your build definition renamed.
Make sure your build definition has successful builds, and it has
'Publish Artifact: drop' as the last task (Try both drop to the
server and a file share).
Another place you need to pay attention to is permission. Please
double check your account and those groups which contain your account
have sufficient permission to create release. Check if there are any deny setting, since deny trumps allow in TFS.
Set Inheritance > On, and then assigned full rights to the Administrators and Service groups in the Build (not Release). And this actually should bring back the drop-down content of artifacts versions in Releases.
Here are the documents which explains how to create the release definition and how to link the artifacts. Please kindly go through it in case you need:
Define your multi-stage continuous deployment (CD) pipeline
Release artifacts and artifact sources
I have a working Jenkins TFS setup, but can't figure out how to stop the Jenkins TFS plugin from deleting the whole workspace and downloading it again each time.
I just want it to do the equivalent of "Get Latest" and not delete any files that are up to date.
Here is the message I'm getting in the console when this happens:
Deleting workspace as the configuration has changed since a build was performed on this computer.
I can't figure out what is causing this or how to disable this behavior.
This doesn't always happen when I build the project, so something is causing this to happen.
It can happen even if I don't change any configuration stuff in Jenkins.
Option to "Delete workspace before build starts" option is off.
I have found the message in the Java source for the TFS plugin here, but
don't understand what is causing it: Java TFS Plugin in GitHub
Environment:
Jenkins v2.60.3
TFS plugin 5.121.0
Windows 10 64-bit
Java 1.8
Console log when this happens:
Building on master in workspace D:\Jenkins\workspace\XXX
Deleting workspace as the configuration has changed since a build was performed on this computer.
Downloading list of workspaces from https://tfs.company.com/tfs/Projects...
Deleting workspaces named 'MASTER-XXX' from computer 'ALAN-XXX'...
Deleted 1 workspace(s) named 'MASTER-XXX'.
Querying for remote changeset at '$/XXX' as of 'D2017-08-29T09:46:26Z'...****
In your Jenkins Project configure Page ,there is an option for deleting workspace before build starts in Build Environment section. Double check if you are checking this option or not.
The plugin checks the latest build configuration and compare it with the current job. If there is any difference/change exist, you will see that message. The configuration it checks is the settings in "Source Code Management". Since you mentioned that it also occurs when you didn't do any change, I suspect that it may caused by some variables you used in "Workspace name" changed. You can also check and compare the "build.xml" for the two builds in Jenkins Jobs folder to see what change cause the issue you meet.
At project > settings > versions you can create versions and apply Build and Release on a version. I totally understand what Release means here (it applies a release date and sets the state to released), but what does Build mean here?
This is an excerpt from official JIRA documentation:
Build the release.
The next step is to build the release. A release is essentially a snapshot of the artifact(s) and related metadata that will be deployed. A release is created from a single build.
If you have connected JIRA Software to Bamboo, you can automatically run a Bamboo build when you release a version. Otherwise, if you haven't connected JIRA Software to Bamboo, or you are using a different build tool, you will need to run your builds independently.
So, primary purpose of the build option is to automatically run Bamboo build if Bamboo and JIRA are connected.
I would like to access some files from source control (tfvc) while release management.
The sources I found are either build (type "Build") and the whole source tree (type "Team Foundation Version Control").
The type "Team Foundation Version Control" seems to match, but it is not allowed to select sub folder, e.g. "$/MyApp/branches/V2/scripts".
Do I need to create an artifact for the script files?
Instead of linking in a separate repository, I'd strongly recommend either publishing them as a build artifact (as the other answer mentions) or publishing them as a versioned NuGet package.
The reason is because everything that goes into a deployment should be versioned together. Scripts that are changing out of sync with everything else can cause abrupt deployment failures for unknown reasons. Let's say you linked those scripts in as an artifact and started a deployment along your pipeline from Dev -> Production. Dev deployment is fine. QA deployment is fine. Staging deployment is fine. Production deployment... fails? Because of an error in the scripts?
Whoops, someone committed a change to those scripts and introduced a bug. But the scripts weren't versioned, so you had no way of guaranteeing that the scripts being used in prior stages were the same as the scripts being used in your production stage.
You can save your source code as a artifact in your build process. Use the "Publish Artifact" step to publish your source code in Tfs or on a unc path. After that release management downloads your artifacts as the first step.
We had a working build for our solution, but when we added a new project, it stopped working. The build runs "successfully" and the log shows: Run MSBuild for Project -> Built [my solution] for target(s) publish (same for all projects), but it doesn't actually build anything.
The problem seems to be in the build configuration. My build process definition is set to build for my custom configuration (ForMSBuild | Any CPU), but something is wrong with the way TFB is interpreting that definition (I need that custom configuration because I copy some .dlls to a designated folder to include in a publish process in order to be available for a ClickOnce install).
At one point, only the new .dlls added to the solution weren't building (even though they were listed in the Configuration Manager with the Build check box checked). So I re-created my custom configuration, ensured that all my .dlls were checked to Build under (ForMSBuild | Any CPU), and now none build. I have opened the source on the build machine directly in Visual Studio (2012) and verified the settings for my custom configuration.
Edit the Build Definition, in the Process tab click the ellipsis next to Solutions To Build, go to the Configurations tab and ensure TFS Build is set to build the configuration you want it to:
It turns out that I actually had the main startup project not checked to build. Really stupid mistake, but I sure wish MSBuild hadn't spit out all those incorrect messages.