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
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.
I create a instance with CentOS-7-x86_64-GenericCloud.qcow2. And then, i listed the modules with the 'chkconfig' command. In this list cloud-init module and other modules are on. When cloud-init is on, i tried to reboot the instance. It takes almost 5 min. It is too long. How can i resolve this problem?
It could be a network problem that prevents cloud-init to execute correctly. You can check it analysing cloud-init logs at /var/log/cloud-init.log and /var/log/cloud-init-output.log.
Which hypervisor/cloud are you working with?
Its hard to diagnose your problem with the limited information here. There are a lot of recent changes in cloud-init with regard to OpenStack and CentOS. We've recently added a copr repository for delivering cloud-init rpm builds from trunk.
If you are still having issues, please file a bug in launchpad.
Follow the instructions there on what information to provide.
Feel free to ask for help in irc on Freenode #cloud-init.
I've got a number of batch processes that run behind the scenes for a Linux/PHP website. They are starting to grow in number and complexity, so I want to bring a small amount of process to bear on them.
My source tree has a bunch of cpp files and scripts, organized with development but not deployment in mind. After compiling all the executables, I need to put various scripts and binaries on a cluster of machines. Different machines need different executables, scripts, and config files for their batch processes. I also have a few of tools that I've written that belong on every machine. At the moment, this deployment process is manual and error prone.
I'm guessing I'm just going to end up with a script that runs at the root of the source tree and builds a smaller tree of everything necessary for any of the machines. Then, I'll just rsync that to the appropriate machines. But I'm curious how other people are managing this type of problem. Any ideas?
There are a several categories of tool here. Some people use a combination of tools from these categories. I sometimes use, for example, both Puppet and Capistrano. See Puppet or Capistrano - Use the Right Tool for the Job for a discussion.
Scripting Tools aimed at Deploying an Application:
The general pattern with tools in this category is that you create a script and/or config file, often with sets of commands similar to a Makefile, and the tool will ssh over to your production box, do a checkout of your source, and run whatever other steps are necessary.
Tools in this area usually have facilities for rollback to a previous version. So they'll check out your source to releases/ directory, and create a symbolic link from "current" to "releases/" if all goes well. If there's a problem, you can revert to the previous version by running a command that will remove "current" and link it to the previous releases/ directory.
Capistrano comes from the Rails community but is general-purpose. Users of Capistrano may be interested in deprec, a set of deployment recipes for Capistrano.
Vlad the Deployer is an alternative to Capistrano, again from the Rails community.
Write your own shell script or Makefile.
Options for getting the files to the production box:
Direct checkout from source. Not always possible if your production boxes lack development tools, specifically source code management tools.
Checkout source locally, then tar/zip it up. Use scp or rsync to copy the tarball over. This is sometimes preferred for something like an Amazon EC2 deployment, where a compressed tarball can save time/bandwidth.
Checkout source locally, then rsync it over to the production box.
Packaging Tools
Use your OS's packaging system to generate packages containing the files for your app. Create a master package that has as dependencies the other packages you need. The RubyWorks system is an example of this, used to deploy a Rails stack and sample application. Then it's a matter of using apt, yum/rpm, Windows msi, or whatever to deploy a given version. Rollback involves uninstalling and reinstalling an old version.
General Tools Aimed at Installing Apps/Configs and Maintaining a Set of Systems
These tools do not specifically target the problem of deploying a web app, but rather the more general problem of deploying/maintaining Apps/Configs for a set of servers, or an entire company's workstations. They are aimed more at the system administrator than the web developer, though either can find them useful.
Cfengine is a tool in this category.
Puppet aims to improve on Cfengine. It's got a learning curve but many find it worth the time to figure out how to do the configs. Once you've got it going, each box checks the central server periodically and makes sure everything is up to date. If someone edits a file or changes a permission, this is detected and corrected. So, unlike the deployment tools above, Puppet not only puts files in the right place for you, it ensures they stay that way.
Chef is a little younger than Puppet with a similar approach.
Smartfrog is another tool in this category.
Ansible works with plain YAML files and does not require agents running on the servers it manages
For a comparison of these and many more tools in this category, see the Wikipedia article, Comparison of open source configuration management software.
Take a look at the cfengine tutorial to see if cfengine looks like the right tool for your situation. It may be a little too complicated for a small website, but if it is going to involve more computers and more configuration in the future, at some point you will end up using cfengine or something like that.
Create your own packages in the format your distribution uses, e.g. Debian packages (.deb). These can either be copied to each machine and installed manually, or you can set up your own repository, and add it to your list of sources.
Your packages should be set up so that the scripts they contain consult a configuration file, which is different on each host, depending on what scripts need to be run on each.
To tie it all together, you can create a meta package that just depends on each of the other packages you create. That way, when you set up a new server, you install that one meta package, and the other packages are brought in as dependencies.
Although this process sounds a bit complicated, if you have many scripts and many hosts to deploy them to, it can really pay off in the long run.
I have to roll out PHP scripts and Apache configurations to several customers on a frequent basis. Since they all run Debian Linux, I've set up a Debian package repository on my server and the all the customer has to do is type apt-get upgrade and they get the latest version.
The first thing to do is get all these scripts into a source control repository (svn or git are good) so that you can track changes to these scripts over time.
If you are interested in ruby, check out Capistrano, it is well suited deploying things to multiple machines in a cluster, and is fairly easy to set up. It can read files directly from your version control system.
Puppet is another tool that can be used in this situation. It is similar to cfengine - you create a model of the desired deployment and Puppet figures how to get the environment to this state.
The company I work for writes a lot smallish Perl and Bash scripts to massage data into something usable for our software. These scripts, like any code, can change. I provided them CVS because of the file versioning rather than repository versioning. Anyway, I am thinking out a deploy tool to get the scripts from development to production. The production server will have it's own simple versioning system in that if one of the scripts' md5 sum does not match the one in a database it will not run the script and email the appropriate parties.
I want to force the programmers to deploy the most current CVS version of the script. If it is not the most current it should die with a message telling them they have to check in their version first. I realize there might be cases where you need to deploy an old file. Those would be exceptions and could be handled as such.
What's the best to do this? Is it just as simple as doing a 'cvs diff' ?
if you going to write some kind of distribution script it should be relatively simple
1) The script should be committed in your cvs repository
2) I advice to call the script from your makefile (or any build system you use)
something like this
make dist
and the dist rule will call your script.
3) script will perform
cvs up -An
and analyze the output to look for M or C or A or R status
by redirecting the output to grep for example.
grep -c ^[MCAR]
if count > 0 you got a problem.
4) if one of above found fail the build script
5) if not create the tar or any other form of distribution you are using
To deploy older version you can make an -A as a parameter by default set to -A and overridden for example by shell variable to be for example -r tag-3.14.4 .
I worked on an internal tool that did deployments.
It was designed for the enterprise (and to meet SOX regulations), and so it relied on approvals to deploy code.
Because of this, we deployed the version of code the developer specified in the request, not the latest version. The reason is that a developer may need to make changes, place into test, meanwhile other changes take place. These newer changes have not gone through the test (QA) phases, but the developers original version has, so we would deploy that version.
All that to say, I would design it in such a way that a version number could be specified, and if no version number then push the latest.