I have an old Octopus release, unfortunately some of the variables from the snapshot variables taken at the time it was created are not longer in the variable configuration section or it has different values and I want to use that same configuration in a new release I just created. is it possible to take the snapshot variable from the old release and use it into my new release? or a way to restore the missing variables in variables section from that old release snapshot variables?
To my knowledge, it is not possible. You could clone the project and update the variables manually from the snapshot and create the N+1 release with this. A little tedious, but should work.
Ref: https://help.octopus.com/t/create-release-with-specific-snapshots/19410/2
Related
How to pass variable from build to release in azure build to release pipeline:
We have variable in CI pipeline --> we have to pass that variable in Release pipeline--> that variable has to set in another yaml file.
is this possible?
For now, we could only set a variable in a variable group as a static value and use it in both build and release.
Detail ways please refer Marina's answer in this question: VSTS : Can I access the Build variables from Release definition?
But according to your description, what you want is to set the variable during the build and then use it in the release pipeline.
The is no official way to pass variables follow this. As a workaround, you could use some 3rd-partly extension, store the values in a file (json, xml, yaml, what have you) and attach that as a Build Artifact. That way you can read the file in the release and set the variable again.
Take a look at this similar issue: How to get the variable value in TFS/AzureDevOps from Build to Release Pipeline?
We use gradle and have our Version-Number stored in gradle.properties.
Further we use "SNAPSHOTS" to identify builds from develop.
When creating a new release we remove the SNAPSHOT Postfix in develop, create a Release Branch and increase the Version-Number to the next SNAPSHOT Version in develop.
This process prevents merge conflicts for the gradle.properties, when finishing the release branch (which merges the last changes from release to develop branch).
But now we have the problem, that we have merge-conflicts (or worse fast-forward merges!) when creating hotfix-branches from master and merging them to open release branches and develop.
The same problem occurs with Maven Projects, where the Version-Number is located in the pom.xml.
Is there another good solution to prevent this problem? I was thinking about externalising the version-number and passing it e.g. via Build Parameter or store it in a file which is not under version control but this has the disadvantage, that you can't identify the version from the source.
Any help would be appreciate.
UPDATE
Another Idea is it, to use the Branch- / Tagname to identify the Release-Number.
I encountered an error in one of our deployments today so i applied a fix to one of the processes and tried again, however the fix was not picked up. I found i had to create a new release. Is there anyway to force octopus to pick up a change if you try to run the current release again?
That's a core concept in Octopus and its as design. Check the Release Snapshots section of the documentation.
You can update the variables for an already-created release, but not the steps.
We'd like to increment the minor version of our application each time we create a new branch for release. So if, for example, the current version is 4.17 the next branch we create would automatically increment the version number to 4.18.
Our scheme is that the code follows the following path:
Dev -> Test -> Staging
so that the testing happens on code we think has the functionality required and only that code that passes testing is available for release.
Then when the time comes for a new release we take a new branch of Staging, so we have the following structure:
Staging
|----> Release 4.1
|----> Release 4.2
...
|----> Release 4.17
There is no cross pollination between the release branches.
So what we need is something that will increment the minor version number when a new branch is taken. We can reset the version number of the application in Dev/Test/Staging to anything that needed for this to work.
Is this possible with TFS/VS 2013 out of the box?
That is a bad smell!
You have to do that on one branch, and no in all... And not change the assembly number in a manual way...
The TFS Versioning could help you to do this.
In the community build tools you will find an activity called TFS Version. This tool can, in its default configuration, strip the version number from the build name. If you name your build for the branch to be mybuild_7.8.0$(.r) the tool can be configured to pick up that version and store it in a variable. You can then use that variable to update the AsemblyInfo.* file versions.
This is the correct way to do what you are asking. Do not check the changes in, and indeed set the checked in numbers to be 0.0.0.0. This way you will be able to identify when a cheeky developer has done a local push and when it came from a build server 😃
https://tfsbuildextensions.codeplex.com/wikipage?title=How%20to%20integrate%20the%20TfsVersion%20build%20activity&referringTitle=Documentation
I'm learning how to use the Maven Release Plugin and I have a question with the process of tagging/branching. I'm working on a project called "test" version 1.0-SNAPSHOT. I'm ready for the release. I can prepare the release and perform the release but Maven only creates a tag and I also want a branch for maintenance (bug fixes). I know that there is a possibility to branch with the Release plugin, but the branch goal doesn't create a tag also. I understand that when you want to branch, you don't want to tag. But, generally when you create a tag from the trunk (because release 1.0 in this case), you would want to branch for future maintenance.
Is there a way to configure the prepare/perform goal(s) to also branch the project before or after creating the tag?
Thanks
AFAIK no. But simply copy the /tag/test-root-1.0 to /branches/test-root-1.0. Then you need to update the versions in the pom. For this you can simply use the "mvn versions:set" goal and set the version to "1.0.1-SNAPSHOT". You are probably up to scripting these two commands in bash script if you need to make it look as one :-)
You might want to consider integrating the maven-scm-plugin into the mix. Either scm:tag or scm:branch before or after your release goals should do the trick.