One of a very kind volunteers helped to get M2Crypto almost to the shape that it builds on Windows. We use Appveyor CI for testing (I am a Linux guy, so I don't even have an access to a Windows machine), everything works well, when it does, but it is quite unreliable. M2Crypto is using swig and downloading it for every job seems quite unreliable. Any ideas how to make choco more reliable?
Or, would it be possible to restart just one job (not whole commit), so that when this happens, I could get passing commit with restarting a job?
Thank you for great service.
I would recommend Caching chocolatey packages.
Restarting a single job in the matrix is still not implemented.
Related
The "proper" way for an installer to work is to allow a flag like -norestart, so a bunch of installs can be ganged, and even if all of them trigger a reboot, they can still all complete and I can trigger a reboot at the end. Works a treat. But Autodesk, being Autodesk, has come up with a new installer that no longer supports any kind of restart suppression. They prioritized eliminating unnecessary reboots, but removed the ability to suppress actual required reboots. The gist being any automated install of multiple Autodesk products can now fail because the first one could trigger an unsuppressed reboot.
So, I am looking, as always with Autodesk, for a way around their, um, lack of good prioritization. Is there a mechanism in Powershell to block all installer initiated reboots? Or am I dependent on them getting their !#$## together?
I have a folder like c:\chocopkg where I put a couple of packages which I can't find on the official repo.
Creating nupkg archives was really simple and fun. Instead, the Automatic Updater (AU) is too much for me: there is no simple cinst au; one should clone a git repo and also setup a new one even for a local run.
What I need is very simple. I added a script <package>\tools\chocolateyBeforeUpgrade.ps1, with trivial Invoke-WebRequest regexps. It checks for new versions on the vendor's site and can update chocolateyInstall.ps1.
My first question is: Is there some config option to have cup all running a script like this before checking for package status?
If this is not possible, it would be also simple to wrap cup in a, say, cup2 checking and running automatic upgrades, but what file should this wrapper edit before giving control to actual cup?
cup page just says it "upgrades a package or a list of packages", but I don't understand how. I can speculate it looks at the .nuspec version. However in a local share there is no such info without unzipping the .nupkg file and for remote packages this would require a possibly large download.
AU essentially does what you'll need, even if it is a little more setup and work. I know it may feel like too much to start, but you can just start with the files that run the updates.
What I need is very simple. I added a script <package>\tools\chocolateyBeforeUpgrade.ps1, with trivial Invoke-WebRequest regexps. It checks for new versions on the vendor's site and can update chocolateyInstall.ps1.
This isn't going to help with upgrades as it is a chicken and egg scenario. You need the updated package first to be able to upgrade a package. So putting something into beforemodify or the install script is only going to help you on installation. BeforeModify only runs from the already installed package on upgrade/uninstall, so unless there
I'm using this amazing IPython notebook. I'm very interested into parallel computing right now and would like to use MPI with IPython (and MPI4py). But I can't start a cluster with
ipcluster start -n 4
on Windows7. I just get back "failed to create process". If I use the notebook and start a cluster in the "Clusters" register it's all working fine. But with cmd (even with admin rights) I just get this message. Same with all attempts of using MPI (MPICH2). All path vars are set. Maybe this problem has no connection to Python at all...
I can't say anything about IPython's parallel features, but if you're having problems with MPI in Windows in general, I would offer these suggestions. I've had quite a few issues in the past in trying to get MPI working in Windows. The most convenient method for me in the past has been to use an OpenMPI Windows binary http://www.open-mpi.org/software/ompi/v1.6/. These are now only available in previous releases. And even then, you might have to try more than one before you find one that works. I don't know why, but the latest didn't work on my machine. The release before that one did, however. After this, you have to call mpicc and mpiexec from the Microsoft Visual Studio Command Prompt or it won't work (without a lot of other stuff).
After you have verified that MPI is working, you can try installing mpi4py separately and see if that works. In my experience, sometimes this has worked fine and sometimes I've had to wrestle with configurations. You might just try your luck with an unofficial, prepackaged binary (for example, http://www.lfd.uci.edu/~gohlke/pythonlibs/).
Hope this helps!
I have been tasked with looking into our deployments, and seeing where they can be streamlined. Right now we have 4 different configurations (Debug/Dev, Test, Staging, Release) and 4 *.config files. We have a task that will overwrite app/web.config with the appropriate *.config pre-build time based on the active configuration. An MSI is created, and we do a full deployment of the component on release night.
This is not entirely ideal because if we change something in a config file, or fix the spelling in a specific view we have to re-deploy the entire thing. Not to metion that the MSI will occasionally require a reboot. One other option that has been brought up is instead of creating MSIs we could create custom deployment/rollback scripts and have the ability to do incremental release.
Has anyone here tried deployments both ways? What are some of the pros/cons you have found? Is there a third way we haven't thought of?
edit: Just to clarify a few things...We don't deploy to customers. All software is deployed to our servers. (a few sites, and a lot of windows services). We never change things in production. We actually use the built in system within VS to create the MSI, so that part isn't the terrible part. To me it just doesn't make sense to redeploy an entire website if you had to change 1 view. We also have to deploy to multiple servers. Right now that is done by running the MSI on each one.
MSI pros:
Application/service/site gets installed and registered like most other Windows apps, and shows up in Add/Remove programs
Some built-in support for re-installing, upgrading
Has some built-in support for installing Windows services/IIS sites/lower-level Windows features
MSI cons:
Seems really cryptic once you get "under the hood"
Seems more difficult to customize than using a custom script
Script pros:
Easier to customize, although certain steps might require lots of/cryptic scripting (working with IIS, lower-level computer administration)
Don't have to deal with low-level weirdness of MSI
Script cons:
.bat scripting is not the most readable or writable language. (Powershell is better, but then you have to worry about whether Powershell is installed on the target machine).
Low-level operations require a lot of administrative scripting for commit/rollback behavior
No built in support for installing or rolling-back (MSI has some support built-in)
One thing I've come across that helps with MSIs is WiX (http://wix.sourceforge.net/), but even WiX seems pretty cryptic in a lot of ways. We use a combination of MSBuild and WiX to do automated builds and deployment/installs, and it works okay for us.
Overall, I'd probably lean more towards doing MSI/WiX (or other installer toolkit) deployments over scripts. MSIs are the standard way of doing installs on Windows, and once you get it working, you usually don't have to change too much. MSBuild or some other build framework (NAnt, etc.), can be useful for setting up the deployment (renaming files, doing string replacements, etc.), before putting together the final MSI package.
Running a dev company that build web apps for five years we struggled with this and tried a bunch of solutions. Here are a couple tips:
Always replace the entire web directory with your code (except if you have content generated by the web site, like a CMS). It's pretty fast to do this and incremental deployments can introduce phantom bugs if files are left around.
Have your build process (Nant, MSBuild, whatever) mod the .config files for each environment and build for what you push for. Alternately you can use registry settings so that the .config files are the same but that means a dedicated machine for each environment. May or may not be an issue.
Don't make changes in production. If you need to make changes (spelling errors on site) make those top priority to get changed in dev so that you don't overwrite them with the next push.
If you aren't using MSI's then make sure you have a rollback process. Keeping a copy of the site just before you changed it really helps when something unexplained goes sideways during a roll-out.
I don't know that these tips point to MSI or script. I think it's a matter of which you are most comfortable with. MSI's can be hard to customize, but easy to run and manage. Microsoft has lots of tools for managing roll-outs of MSI's across an organization or farm. Scripts may require custom tools and custom tooling or lots of manual work on the production end.
We ran scripts with Nant and a custom deployment harness. These days (VS2008) building deployment packages is much easier.
Your best option is to get a decent MSI builder to do the job with - i'm talking about InstallShield etc (there are a couple, so do look around). While these invariably cost, they can save you a huge amount of time/money/pain further down the track. Having said that, the pain is not totally eliminated, just reduced :)
Anything tricky you need to do can be done as a custom task within the msi - and you can even do this with the setup builder that comes with Visual Studio (if you are using VS).
I have a suggestion for your config files - include all four in the msi, and then have a public property which can be set from the command line. You can then modify that public property to install the appropriate config file (and have the default value of that property set so that the release config gets installed). That way, your customers just use the msi and get the correct config file, but your test team can get their config file by changing the value of the public property; the command line they would use to do the install is this:
msiexec /i "MyInstaller.msi" CONFIG=test
You can do install scripts quite easily, but as already mentioned you also need to script the uninstall. Using install scripts precludes you from getting Windows certification for your product should you look at getting that done. But that doesn't mean you shouldn't use install scripts, they may be the perfect fit for your needs. Alternatively you may look at using a combined script/msi approach by having your scripts run as custom actions from within the msi.
In your opinion, are MSDeploy packages a good option for giving to an end user to install a webapplication on their system. How does it compare with, say, the experience of using an MSI file to install a web app?
Has anybody tried wrapping up an MSDeploy package inside an MSI package? Would it work?
MSDeploy was described to me as a tool that helps synchronize web sites between machines, much in the way that AppCenter used to replicate a well configured master to many machines. The Windows Installer (MSI + WiX CustomActions for IIS and SQL config) is about applying packages to a machine that modify state in a transaction. It follows the more traditional packaged software model.
Those are two different approaches to the problem of configuring machines. Each is optimized around a different set of requirements. MSDeploy = replicating machine state. MSI = apply changes in transaction.
Could you throw MSDeploy into an MSI? Probably. Would it work well? Maybe, if you ignore the part about transaction. That in my mind is the key difference. In environments where you want to declare the configuration you want distributed and have it either apply fully or not apply at all (i.e. don't end up in an intermediate/busted state) then package based installation seems appropriate.
If you have a machine that you configured just right and want to make a bunch of machines look like it (and are willing to take a failed machine out of rotation and repeat the process until it is beaten into submission) then MSDeploy seems appropriate.
There isn't enough information in your question to suggest which works better... but I don't think they go together. <smile/>