I have a project hosted on GitHub and I have it compiling with Appveyor.
I would like to set up Appveyor so that each build is deployed as a GitHub release, but with each build overwriting the last. This way there will only be one GitHub release from Appveyor that will always have the latest build attached.
I can't see how to do this, because if I specify a release in appveyor.yml I get an error saying the release already exists (yes I want to overwrite it), and if I don't, then each deployment creates a new tag with the current build, which will litter the repository with useless tags.
On top of that, every time the release gets deployed, it creates a new tag which in turn triggers another Appveyor build. This means every push to the repository triggers two identical builds.
Has anyone worked out a way to deploy to the same GitHub release continuously, replacing the files with the latest versions, and to prevent a new Appveyor build from being triggered in response to an Appveyor deployment?
You can add force_update: true to GitHub deployment provider settings to overwrite existing release.
Related
I am trying an automated build process in Azure DevOps for Salesforce. whenever a change is pushed to the repository, my build is triggered and it is working fine and pushing the changes to the related sandbox. Here is the proof for the same
Success Build Process.
The configuration of the build is Build configuration.
The build is working fine as expected. I now want to create a release which will push this change to a different environment, and I don't want this to be automated, hence the option of creating the release. The build path to the ant file in my release is exactly as it should be but I am getting this error. Release Error.
The release configuration is Release configuration
My Repository folder structure is: Folder structure. and my build.xml is within the deploy folder.
I don't know what I am doing wrong but the release is always failing and giving me the error which says:
Error: Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Not found antBuildFile: D:\a\r1\a\deploy\build.xml
Based on the first image (Success Build Process), seems that you already have deployed your changes on that sandbox. Working with metadata deployment in Salesforce is different from java and .net, keep in mind that you already have the "executables", all those XML are already the code that you will change on the environment.
The second point is that on release you are in another agent, Buil and Release pipelines runs have their own lifecycle, so the code existing at the Build pipeline is not available until you send it on "drop" artifact, see Publish Build Artifacts task documentation. So that use copy task to put build.xml on publish folder, then you'll be able to use it on Release pipeline.
When you are executing ant go the /deploy folder and execute your command or check for your ant version using ant -version command.
I have successfully created a Build definition in VSTS for some SharePoint client side projects that I'm working on. I tried creating a Release definition but I can't seem to find any way for me to copy/download the artifacts created from my build definition locally. I may be missing something since I'm still quite new with VSTS but I can't seem to figure it out.
To downbload build artifacts from release when build successful, you can specify the release definition as below:
Add the build artifacts with latest version in release definition.
Enable Continuous deployment trigger for the artifacts.
Select the private agent which you want to download on the local machine.
Now when a build succeed, a new release will be triggered to download the latest build artifacts.
I have a .NET Core project that is auto-built in Appveyor and deployed to Nuget. By default, every successful build causes a new Nuget release.
However, there are many cases when a new release is meaningless because the library's actual code has not changed:
Readme updated
Unit tests added
Appveyor configuration changed
Other cases
It is possible to configure the build so that Nuget publishing only runs if there are changes in the actual code (for example, in folder X)?
There are a few options.
Commit filtering. Note that with it the whole build, not just deployment will be skipped if nothing in folder x changed. You may need a build without deployment at least when unit tests added. As a workaround consider adding separate AppVeyor project which will build and deploy only if folder x changed and keep current project to build every time, but not deploy
Inspect changed files with script. Please check this sample on how to check those files if you use GitHub. So if you see that files in folder x changed, you can set some custom environment variable (lets say you call it deploy_nuget) to true, and use it with a conditional deployment.
In VSTS online, I have in my Release process (Under Triggers) the Continuous Deployment checked. On the Set trigger on artifact source, I put a Tag condition (with tags) set to Automated.
I also have a tag in the Build Process. (Correctly adds the Tag to the build)
But my release is not triggered automatically? In the Deployments status (In my Build) it says "Tags set for release trigger did not match the tags in build branch". But they match (See pictures). What could be the issue?
This is because you added the tag Automated after the build is finished (by label source or manually). This can’t trigger CD release. Tags should be add during a build (not a build is finished). So you can add a power shell task with inline script in your build definition:
Write-Host "##vso[build.addbuildtag]Automatd"
Then the release will be trigger after build is finished.
I do this a different way very similar to:
How to trigger VSTS build and release when pushing tags?
In my Release Pipeline I add a branch filter to 'refs/tags/' or 'refs/tags/v' for the Continuous Deployment Trigger, or anywhere else where I want to filter action in my Release Pipeline. The good thing is that you can apply your Git Tag AFTER your build is complete, just like you prefer. This is optional, but I use Git in conjunction with GitVersion.
Also, please be aware that Git Tags and Build Tags are not the same. Git Tags are stored in the Git repository while Build Tags are associated with a VSTS/Azure build summary. Don't get confused with the two.
For future readers it looks like you can now trigger a release even when a tag is added to a build at any time (not just during a build).
Create a release when tags are added to an existing build. Upon enabling this option, a release gets created when tags are added to an existing build that has not been released. This could lead to deployment of an older build to the environments.
I was hoping for some guidance on the best way to promote a build through its environments.
We have 3 environments, DEV, STAGING, PROD.
The DEV Jenkins build is running in a continuous integration set-up, as code is checked in to subversion, Jenkins will run a new build (clean, compile, test, deploy).
The tricky bit is when it comes to STAGING and PROD.
The idea was to be able to manually promote a successful DEV build to STAGING.
STAGING build would check out the DEV's SVN Revision number, build, test, deploy to staging and finally create a branch in SVN.
Lastly the release manager could manually promote the STAGING build to PROD.
PROD build would check out the branch from the previous STAGING build, deploy to PROD and tag the branch as a release.
I have tried to use a combination of the Promotion Builds Plugin and the Paramterized Trigger Plugin but with no luck. The Subversion Revision number doesn't seem to get passed between DEV build to STAGING build.
Does anyone have any guidance on their process to promote a build through multiple environments?
Another approach is to make use of the Artifact storage Jenkins provides coupled with the Copy Artifact Plugin.
When a build is completed, you could instruct Jenkins to persist your application, either as a compressed zip/tar.gz or as an application bundle (jar/war)
Trigger a downstream job and use the Copy Artifact to retrieve the recorded artifact from the upstream job (or use parameterised builds)
Deploy/Unzip artifact as necessary - Build shell script/maven deploy?
Retest application using the same sources/binaries as was created in step 1
Repeat for PROD as necessary
This approach would allow you to fingerprint the artifacts, and thus Jenkins would link builds together in the UI, as well as allow more formal sign off.
In this scenario, why do you need to go back and label the branch in svn? We don't use svn, but w/ TFS, when Hudson/Jenkins gets the code, the changeset number it has retrieved is in the build log. So we know what code the build came from, and could get back to it at any time.
Then we promote the build from environment to environment using Hudson, the source control system doesn't need to know where the code is deployed.
If it's absolutely necessary to store the SVN Revision ID, then add a build step to your DEV job that copies it to a file. Something like this:
echo %SVN_REVISION%>revision.ini
or something like this:
echo MY_SVN_REVISION=%SVN_REVISION%>revision.ini
Then artifact revision.ini. When doing a STAGING build, use the Copy Artifact plugin (as mentioned by a previous user) to retrieve the revision.ini file specific to the build and load it into a variable. Then use that variable in a command line call to "svn" to build the tag.