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.
I am using TeamCity Professional 8.1 and YouTrack 5.0.6.
I have managed to fill "Fixed in build" field in YouTrack with two step workflow.
I am using #issue-id Fixed command in my Merucrial commit message to change the state of issue in YouTrack.
I made some changes in code ( not related to fixed issue) and I push changes to the server.
When TeamCity finishes the build with changes from the second step it fills the "Fixed in build" field of my issue with the build number.
But the issue was actually fixed in the previous build...
So I want to be able to fill the "Fixed in build" field right in the first build that includes the command to change the state of the issue to Fixed.
Is this possible?
Edit: I have fixed my issue by changed the issue prefix from number "1" to my project name "csv".
Please uncheck 'Process Resolved Issues' option in mapping dialog and make sure time on TC and YT is in sync -- if YT decides a build was created before the issue was fixed, it will not set it into fixed in build.
I am trying to get integration between our YoutTrack and our TeamCity working. However I cannot get YouTrack to fill out the "Fixed in build" field:
Using TeamCity 7.1.3, YouTrack 5.0.2.
TeamCity integration setup points out the "Build Field" to YT's "Fixed in build"
YouTrack correctly shows TeamCity builds in tab "TeamCity Changes".
User names map correctly.
YouTrack commands by VCS commit comments work correctly.
Simple YouTrack issue referencing from commit comments works correctly.
However, no matter what I seem do to, the "Fixed in build" field remains at "Next build".
I tried checking the "Add each build to list" in YT setup. Now the build numbers correctly goes into the Build bundle, but still "Fixed in build" is not set. I also tried with both open and closed issues with no effect.
Any idea what I am missing?
You have to mention the issue in a commit before you mark the issue as fixed. So when you mark the issue fixed it gets set to next build, and on the next build that succeeds you get the fixed in build set - assuming the build that succeeded was the one linked to that youtrack project.
For the longest time you had to have the issue marked fixed in youtrack before any builds would cause the fixed in build to be set.
So, commit with issue ID, then mark issue fixed in next build. You can refresh the teamcity integration from the issue so it picks up the build.
First I fix the issue in the code. Commit the change to source control. Then in YouTrack - I mark the issue "Fixed"
You can also manually link the issue to the commit.
I decided to use the following pattern after reading semantic versioning at http://semver.org/. However, I have some unsolved issues in my mind in terms of automaticng and integrating SDLC tools.
Version Pattern:
major.minor.revision.build
Such that;
Major: major changes, should be increamented manually.
Minor: minor changes, should be increamented automatically, whenever a new feature or an enhancement to existing feature is solved in issue tracking system.
Revision: changes not affecting the minor changes, should be increamented automatically, whenever a bug is solved in issue tracking system.
Assume that developers never commit the source unless an issue has been solved in issue tracking system, and the issue tracking system is JIRA in this configuration. This means that there are bugs, improvements, and new features as issue types by default, apart from the tasks.
Furthermore, I am adding a continous integration tool in this configuration, and assume that it is bamboo (by the way, I never used bamboo before, I used Hudson), and I am using Eclipse IDE with mylyn plugin and plus the project is a Maven project (web).
Now, I want to elucidate what I want to do by illustrating following scenario. Analyst (A) opens an issue (I), which is a new feature, related to Maven project (P). As a developer (D), I receive an email about the issue, and I open the task via Mylyn interface in Eclipse. I understand and develop the new feature related to issue (I). Consider, I am a Test Driven Development oriented developer, thus I wrote the Unit, DBUnit, and User-Acceptance (for example using Selenium) tests correspondingly. Finally, I commit the changes to the source control. I think the rest should be cycled automatically but I don't know how can I achieve this? The auto-cycled part is the following:
The Source Control System should have a post-hook script that triggers the Continous integration tool to build the project (P). While building, in the proper phase the test code should be run, and their reports generated. The user-acceptance test should be performed in a dedicated server (For example, jboss, or Tomcat). The order of this acceptance test should be, up the server, run the UA test, then generate the UA test reports and down the server. If all these steps have been successfuly completed, the versioning should be performed. In versioning part, the Maven plugin, or what so ever, should take the number of issues solved from the Issue Tracking System, and increment the related version fragments (minor and revision), at last appends the build number. The fragments of the version may be saved in manifest file in order to show it in User Interface. Last but not the least, the CI tool should deploy it in Test environment. That's all auto-cycled processes I want.
The deployment of the artifact to the production environment should be done automatically or manually?
Let's start with the side question: On the automatic deployment to production, this requires the sign off of "the business" whomever that is. How good do your tests need to be to automatically push to production? Are they good enough that you trust things to just go live? What's your downtime? Is that acceptable? If your tests miss something, can you rollback? Are you monitoring production so you know if you've introduced problems? Generally, the answers to enough of these questions is negative enough that you can't auto-deploy there as the result of a build / autotest event.
As for the tracking, you'll need a few things. You'll need all your assumptions to be true (which I doubt they are, but if you get there that's awesome). You'll also need a build number that can be incremented after build time based on test results. You'll need source changes to be annotated with bug ids. You'll need the build system to parse the source changes and make associations with issues. You'll need an API into the build system so you can get the count of issues associated with the build. Finally you'll need your own bit of scripting to do the query and update the build number accordingly.
That's totally doable, but is it really worth having? What's the value you attach to the numbering scheme?
Recently I updated the cigame-plugin for Hudson to version 1.12. Now I recognized, that no build get points at the moment. The builds are SCM-triggered and the CI-game is activated for the project and the user. What is going wrong? How can I fix it?
EDIT: I have to correct, the update to the new version of the plugin isn't the problem. Looking through the build-history I can see, that after this update builds got a score. But at some point the builds are not longer scored. Nothing happened to hudson at this time, no restart, no reconfiguration etc. Simply SCM-changes came in and triggered builds.
EDIT 2: The ci-game-plugin counts a score for builds started manually, but not for builds started by changes in version-control. I have no idea why it behaves this way.
EDIT 3: Further investigation shows that I have this bug with the same stacktrace produced.
This is so specific to the current state of the Hudson plugin ecosystem, I suggest you go directly to the users mailing list with the question, where the plugin developers can help you directly.