After successfully linking a Jenkins build artifact source to Release Management vNext in TFS 2015 Update 2 RTM (adding a Jenkins endpoint, linking to the source through Artifacts tab, finding build artifacts through TFS that were published in Jenkins and verifying by selecting the Jenkins artifacts in the Copy release task), it looks like in the Triggers tab, when trying to select Continuous Deployment, a warning symbol appears and the message says:
Linked artifact sources do not support triggers.
Any idea if it is possible to link a Jenkins build artifact source to trigger releases in TFS 2015.2 in Continuous Deployment? Looks like it only works for TFS builds. I see this link that says "other sources" for builds by using the REST API for RM but when clicking on the link, the section says in the body, "Content not available."
I could reproduce your scenario if choose Jenkins type in Artifacts. But if choose Build type, this warning won't show up.
Continuous Deployment doesn't support Jenkins Artifacts, you can submit a UserVoice at website: https://visualstudio.uservoice.com/forums/121579-visual-studio-2015
Related
I was testing to see if jenkins job's retention policy is respected by artifactory.
I created a simple Free-Style project and uploaded a build to artifactory with option selected "Discard old builds from Artifactory (requires Artifactory Pro)" and I am using artifactory PRO.
The build artifacts and metadata are uploaded and I can see the "Build info json" on artifactory.
According to json schem given under "Build info format" section here, there should be a section like:
"buildRetention" : { // Build retention information
"deleteBuildArtifacts" : true,
..
..
},
In my case it is not visible.
Am I doing something wrong.
Jenkins: 2.263.4
"artifactoryPluginVersion": "3.11.4"
artifactory: 7.4.3
and I am using generic repository.
In older versions of the Jenkins Artifactory Plugin, the build retention policy indeed uswd to be included as part of the build-info JSON. Artifactory used to read the information from the build-info JSON whenever a build-info was published, and triggered the retention. Today however, the retention request is no longer sent to Artifactory this way. Instead, Jenkins sends a separate REST request to Artifactory for the build retention, right after the build-info is published. This change decouples these two actions, and by that allows triggering the retention when desired in pipeline jobs. See for example hope this is done using the Artifactory DSL for pipeline jobs. In terms of the retention functionality, it remained the same for Free-Style jobs.
In the contest of build retention, it's also worth mentioning that in Free-Style jobs, in addition to setting the "Discard old builds from Artifactory (requires Artifactory Pro)" option in the UI, you should also configure the build retention under "Discard old builds". In this section you can indicate how long to keep old builds on Jenkins. In Free-Style jobs, this configuration is also used to discard the builds from Artifactory.
Is there any options to lock TFS check-ins when the build is failing or three consequent times in Jenkins?
Not totally sure about your meaning of lock TFS check-ins. If you just want a developer checks in changes that break the build. We do not have any build in feature to support this integrate with Jenkins.
However, you can guard some or all of your code base against these problems by creating a gated check-in build definition(TFVC) or pull request(Git) through TFS own build system.
If you are using TFVC, by using Gated build, when developers try to check-in, they are prompted to build their changes. More details please take a look at our official tutorial.
If you are using Git, you could use pull request and branch policy. There is a Build validation setting in branch.
Validate code by pre-merging and building pull request changes
With using both of above method, you could only check in codes/changes when build succeed.
In order to save on the maintenance of build definition I create one build for Gated & Publish.
I also create a release that triger when my build run as deploy (As described in the link)
When build run as deploy (not Gated) there are another tasks that run during the build:
Publish Build Artifacts - upload artifacts
Update Build Name - change the build name to "Auditing [Version]" format
Add build tag - Use to triger release
When I am try to create release manuly I get list of artifacts, some of the artifact are resualt of gated build.
In the image bellow I market the gated build.
I'm interested in keeping a clean list, is there a way to prevent from tfs to add gated build to my articact list
I am working with TFS 2018.2 On-Prem.
Thanks In advance for all.
I would like to know what is the equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions.
1- Is it "Run continuous integration triggers for commited changes" in Gated trigger?
2-Or it is a "Continuous Integration trigger with batch changes checked" in build definition.
I ask this question because I was not able to launch a CI build after successfully Gated Check-in. My CI build does different steps than Gated.
I'm over TFS 2017 (15.117.27414.0).
The equivalent of "Continuous Integration - build each check-in" (XAML definition) in VNext definitions is Continuous Integration trigger:
Enable CI trigger if you want the build to run whenever someone checks
in code.
Select Batch changes check box if you have a lot of team members
uploading changes often and you want to reduce the number of builds
you are running. If you select this option, when a build is running,
the system waits until the build is completed and then queues another
build of all changes that have not yet been built.
Select the version control paths you want to include and exclude. In
most cases, you should make sure that these filters are consistent
with your TFVC mappings on the Repository tab.
You can get more details in the link below:
https://learn.microsoft.com/en-us/vsts/build-release/concepts/definitions/build/triggers?view=vsts
I am trying to setup a continuous integration and deployment for my Xcode project that is in Bitbucket, using Visual Studio Team Services (VSTS).
In my build script for VSTS, that is triggered by changes to the 'develop' branch, I do the following steps:
Pull the 'develop' branch from BitBucket. (Using Get sources)
Increment the build number in my project's plist file. (Using Fastlane)
Commit and tag the build number change back to the 'develop' branch. (Using Fastlane)
Build the project and create the .ipa file. (Using the Apple AppStore extension for VSTS)
Upload the .ipa file for the release script. (Using Publish Artifact)
In my release script for VSTS, that is triggered by a successful build, I do the following steps:
Download the .ipa file.
Publish .ipa to iTunes Connect/TestFlight (Using the Apple AppStore extension for VSTS)
When I commit the version change on the 'develop' branch, it triggers another build in VSTS. Looking through the documentation I find this:
https://www.visualstudio.com/en-us/docs/build/scripts/git-commands#how-do-i-avoid-triggering-a-ci-build-when-the-script-pushes
How do I avoid triggering a CI build when the script pushes?
Add ***NO_CI*** to your commit message. For example, git merge origin/features/hello-world -m "Merge to master ***NO_CI***"
I tried the commit messages:
" ***NO_CI*** VSTS build v1.0.0 (1) "
and
" VSTS build v1.0.0 (1) ***NO_CI*** "
Neither of them worked, the build was still triggered.
So my question is:
How can I use VSTS, Bitbucket, and an iOS project to setup continuous integration and deployment including version number changes in my Xcode project?
For now, you can use VSTS to CI build and CD deploy for your bitbucket repo. But you can’t use ***NO_CI*** to avoid CI build for bitbucket repo.
I posted an user voice Avoid CI build for Bitbucket repo, you can vote and follow up.
The way to add a CI build for your bitbucket repo: build definition -> get source step -> select remote repo -> new service connection or the connection your created -> input your bitbucket repo URL and credential -> OK -> add other task for your needs -> save. Now when new changed are pushed to your bitbucket repo, the build will be triggered.