Is it possible to add a comment to each build such that it is easy to trace back a build of the past (i.o. on ?
Although it is useful (and appreciated!) to be able to revert to previous builds for me it somehow looses a lot of its usefulness if not being able to do this.
This is the workaround I am using…
I use Jira for tracking and put the summary of fixed issues and the release# in the agent or device code as a comment on the top of the code listing. In production I intend to link the IDE build to the Jira release so its traceable.
The build# will be available programmatically fairly soon (in both device and agent) but I suppose that doesn’t really help so much. Have you tried using the build API yet?
Hyperone, Hugo,
Thank you for your comments.
To be honest, to have to go through a lot of fuzz just to be able add a comment to a commit…
I use SVN every day at work, you commit something, you get a pop up to enter your comments in, add the comment and: ready! I would not exactly call that rocket science.
In the log I can see all the versions numbers of a particular file including its commit comments and based on that check via the comments what version number of a file I want to revert to.
In the IMP IDE I have to guess based on time (which I for sure will not know after half a year) when the version I want to revert to was committed. If not the right one, try again, and again…
Pls don’t misunderstand me, I really really like what Electric Imp has become over the years but for me this omission is so basic I do not understand why it is not made possible (in an easy way)!
BR
Moose
The thing here is that our versioning system is too simplistic for serious uses; you want branches, merging, etc, so it’s best to look at it more as a “oh dear, let me go back a few versions” for quick projects.
The point about the build API is that you can write scripts that will be triggered by svn actions and push the appropriate code to the imp servers (including the svn tags auto-inserted into the source if so desired). This then allows you to implement the rich functionality you desire for your workflow.
We’ve already published some node tools, but we’re likely to have some git integrations at some point (if a user doesn’t beat us to it).
One thing that impacts my build numbers is if I need to manually restart the agent through the IDE (I would sometimes do this to test and debug the startup sequencing between agent and device). So every time I need to reboot the agent it creates a new build number. I then cannot distinguish between a build number due to a software change and a build number because I simply wanted to restart the agent.
So some form of comment recording system against build numbers would certainly help in this case.
To gerriko’s point, perhaps just a restart capability without incrementing a build number.
The Build API has an endpoint to restart devices without a Build and Run (so Build # doesn’t increment).
This may not solve your problem immediately, but it opens the doors for tools, browser extensions, etc that can do the things you need.
We also plan to migrate the IDE to use the Build API, and when we do, features like this will be much more straight forward to implement 