I was able to reproduce this, it only happens when a child environment is created for first time. The case is OTTER-121, and wil be resolved in a future maintenance release.

Unfortunately i'm not familiar enough with CakePHP to advise on how to stop the service non-interactively. I would perhaps suggest to modify the batch file to not look for an exit code? BuildMaster will basically just run whatever process you ask to, so the batch file is what's waiting...

Hello Thank you for the reply. I use OTTER for a few weeks now, So I have to understand the otter model :) I will apply my DSC in a classical way (start-DSCconfiguration script) Regards Philippe

For my requirement at hands, simply having an option to include the notes as free text would do, as we won't be putting too much rich formatting notes inside, simply a reference number. Similar with "Additional Options" in Deployment Execution Completed event listener, if we could provide a checkbox to include Notes in Approval Required event listener should be fine for now.

I've updated the proget plugin to support pipeline script. It hasn't had a lot of testing (PC died and haven't had a chance to fully rebuilt it yet) but the changes were minimal so should be fine. It's also built against the latest LTS of Jenkins so I hope that won't be an issue for you. I'm also trying to do the same with the BuildMaster plugin but that one is proving to be harder to do and I've had to raise an issue on the Jenkins mailing list.

Hi Philippe , I think i understand, but it's much easier to visualize :) Especially once we see your data. could you send a screenshot to us via support - at Inedo - dot com? And feel free to hilite the areas, etc. you suggest to improve.

Please disregard now. It's all working fine. Someone changed the issues I was seeing in Jira yesterday and moved them to another release, incorrectly, at about the same time I was viewing them. I got the legacy aspect figured out as well so all of future configs should be non-legacy. Thanks.

One possible way is to still look up user's address from directory as a mandatory (to address), then option to provide additional email addresses (as cc). It can be considered additional behavior, not completely change of the logic. The send-email work-around is fine, the only thing is design the template from scratch is tedious, it'll be good to provide some default template and work from there.

hi Mark, great question. My team pointed me to your question; I actually talk on this topic quite a bit. DevOps is really just a buzzword, and everyone (including Inedo) is jumping on it to describe what we do. But ultimately, DevOps is a process improvement designed to improve release velocity (e.g. going agile) through two means: Automate everything you can Increase collaboration between teams Ultimately it's about improving a process of software release. There's a ton of noise about "best practices" out there, and everyone has opinions. But I think the best way to understand these opinions are to get a feel for the underlying process. Two suggestions for that. Release Management Done Right describes why you should be following a pipeline strategy. Source Control Done Right goes over how source control should/shouldn't be used, and is still quite relevant today (it was written before "DevOps" was buzzy). Now, based on your specific situation, my advice is to start simple. Just change-up your TFS version strategy a little bit -- don't build in each environment, but create a build artifact at the start. You can do this all in BuildMaster. The other tools are nice, but may not be necessary until you run into the problem of trying to have a single tool do it all.

Solution found, wrong app pool user. thks all

The easiest option would just be to use the PowerShell Agent, which does not require any installation and simply uses remote PowerShell. However, if you can't use this or don't want to due to performance issues, you can manually install the Otter/Inedo agent by downloading the manual install package for the latest version of Otter here: http://inedo.com/otter/versions The instructions for installing the agent manually can be found here: http://inedo.com/support/documentation/otter/installation/manual

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

There is no built-in variable function to do that, but it could be done with a custom variable function that does a lookup for the configuration variable based on the environment. Like $EnvironmentVariable(envName) or something. Let me know if you run into troubles, I can probably help! I don't know how easy it would be for us to generalize a lookup function, because there are so many different types of configuration variables (env, server, app, etc), and one might be desired for SErver, Role, etc.

That's what the nuget.exe client does, a Delete method. Yes. That will also remove package from disk and metadata.

Thanks Philippe, looks like you identified the bug and workaround. It will be addressed as OTTER-119

You could just bypass it on the promote page, by selecting "Do Not Execute" and then override the promotion status to Successful. That might be sufficient? Otherwise, we don't have a good way to evaluate whether or not a pipeline stage should advance. Perhaps one idea would to use a variable for targeting? or maybe a (JSON-only) option that says "skipStep" or something that you could have a $Variable as. Just ideas, not sure if they're feasible!

Great question. First and foremost, if you haven't seen it already, take a read through KB#1056: A Comparison Between BuildMaster vs. Jenkins; it gives a good idea of the differences between release automation and continuous integration. Regarding your question ... What I don't understand is what is the advantage of having BuildMaster take over the pipeline with Jenkins doing the build instead of having Jenkins do it? ... it's really like asking, "what are the advantage of having a people-driven release process instead of having continuous builds automatically tested and then automatically deployed from source to production." The answer really depends on the organization. To many, the idea of continuous deployment is terrifying; for others, it's satisfying. What parts in the Blue Ocean screen shot would still be done in Jenkins and what would be done in BuildMaster? In this case, you would use Jenkins to create a release-suitable build; so your pipeline would look more like Build > Run Unit Test > Run Selenium Test > Export to ProGet > Pull into BuildMaster > Deploy to Integration. The "Deploy to Integration" would be triggering BuildMaster. Of course, Jenkins can deploy (or really, "do anything" since it runs scripts you write) -- but BuildMaster's deployment capabilities will almost always be superior. From there, BuildMaster would handle your release process, and actually get it to the proper environments securely, etc.

The resources are embedded in the ProGet assemblies (in this case, InedoLib.dll), so if you can hit the site, then it means some IIS setting is preventing those from being served. It's hard to guess which one... perhaps URL filtering?

Did you change the name of the branch after cloning? When cloned, branches should automatically track the remote branch. One option is to navigate to the local GitRafts directory in the Execution.DefaultWorkingDirectory path (found in All Settings), and delete the local workspace and try again. If you have git installed on the same server as Otter, you can manually configure the repo to track the remote branch using the commands outlined here: http://stackoverflow.com/a/2286030