Where is the proper path for creating files using Ruby on a *nix environment? The files must persist between restarts and releases. Obviously using the project path doesn't work as Capistrano will create a new folder for each push.
Capistrano has a system directory created by default that should be linked to the shared/system directory at the root of your release path. This will persist between deployments.
You should put anything there that is not specific to your deployment, for example, attached files or other user uploads.
In your version control system you should be sure to not deploy this directory as to avoid packaging up your development-specific content. Generally it should be ignored, not included in your version control.
Related
I am trying to maintain my changes to config files of resource.bundle directories from remote cocoapods repositories.
While working on the implementation I am able to make changes locally but I do not own the external repository.I would like to be able to refer to the code owners tags implementing the pods from their repos in my project while maintaining my configuration changes.
It has been suggested to me to create a script phase in my build process that would copy files from a "assets folder" within the project to the finished pod directory after the remote pull and build.
This sounds feasible but I am not sure where to start in this process or what the script would like.
essentially I would have a
root/assetsfolder/resource.bundle
that would need to be copied to
Pods/ExternalPodName/Core/resource.bundle
Any help would be appreciated.
I'm following this site: https://puppet.com/docs/pe/2017.2/r_n_p_full_example.html
In this file path: /etc/puppetlabs/code/environments/production/site/profile/manifests/jenkins/master.pp
Is the directory called 'site' required?
Could the directory called profile above be moved to the modules directory?
I'm using puppetserver version 4.10.12.
Is the directory called 'site' required? Could the directory called profile above be moved to the modules directory?
It depends. In a general sense, sure, you can put your 'role' and 'profile' modules into the environment's modules/ directory. That's where I put mine.
But the writeup you linked explains why it demonstrates using a different directory:
If you deploy your code with Puppet Enterprise’s code manager or r10k,
we recommend putting these two modules in your control repository
instead of declaring them in your Puppetfile. Since code manager and
r10k reserve the modules directory for their own use, you must put
them in a separate directory
If you are not using either of those code deployment tools and don't anticipate doing so any time soon -- like me -- then not only can you put your modules into the modules/ directory, but that's what I would recommend doing. But if you plan on using one of those then do follow the guide in this matter.
My automation deployment environment I have web.war file deployment under tomcat.
Lets assume this web.war application contains mix.jar file which is under /lib directory of web.war archive file.
(mix.jar releases giving by different DEV team and they don't responsible for giving web.war and the organization practice is putting the latest mix.jar file into the web.war archive file manually )
Can anyone help me to automate this process from CHEF recipe ?
Basically what I need during the chef deployment is, putting the mix.jar file into the web.war/lib directory under tomcat container.
Our current practice is open the web.war file from Winrar and put the mix.jar file into it and redeploy it into tomcat.
But I want to automate this process.
Jar files are just zip files so you can probably write some code using either the zip command line tool or the RubyZip gem (I would go for the latter but depends on your comfort level with Ruby code) to do this on the fly, but please don't. Chef is really not built for this kind of task and it will be very frustrating to build the code in a robust manner. If you need it ASAP and want to build a fragile version now and fix the process afterwards that's more understandable, but otherwise probably just talk to your dev team about what this is and why you need it added to their build process. Some problems are best solved with communication rather than code.
I couldn't find a way to do this yet with capistrano, but lets say I have a project like
project
project/src
project/Capfile
project/config/deploy.rb
project/config/deploy/production.rb
project/build
project/build/main.js
project/build/other_src.js
so the intention is to deploy only what I have within the /build sub directory within the project.
I realize I can just move the capistrano files to the build directory, but the directory is build and dropped every time I compile the project, so I need to kept the capistrano files within the root dir of the project.
Any advice on how to do it in Capistrano?
I've always deployed the entire project and then pointed my webserver at the relevant subfolder. Alternately, you can write a custom task to rework the data in the release path.
I am having issues with Jenkins that I am unable to resolve, and all the solutions I've found online I've used in the past, but are not helping.
I am on windows 2008r2, utilizing svn, jenkins version 1.407.
Initially the service failed, and was not resolved with past methods. In the past I have successfully troubleshoot Jenkins by killing hung processes, restoring the war file, ect.
I have attempted a new install with bringing over the files in the jobs folder. The end result was a partially functioning Jenkins would attempt a build it would report no change and not update.
What I'm trying to determine is a list of files/folders beyond the jobs folder that I need to move to the new install. The initial install predates me and was Hudson. The folder has a number of obviously obsolete files and folders (both a jenkins.war and a hudson.war)
Go to Jenkins home folder and collect:
all ./*.xml files in - these are configuration files for plugins and jenkins itself
users/* in case you have security enabled
subversion-credentials/** and secrets/** for any kind of keys provided in jenkins to access svn or other resources
plugins/*.*pi folder for all plugins - you don't need to have the unpacked folders
jobs/*/config.xml - to retrieve all job configurations; jobs/*/nextBuildNumber if you care to continue build numbers
plugins may create additional folders which you may want to use
with that you should recreate Jenkins as it was. Pay especially attention to config.xml file in root folder - this holds main jenkins configuration. If your issue reproduces on new system most likely a plugin is cause for problems - in that case review log files most likely you will find out which plugin causes trouble.
You didn't indicate if you tried new setup with same version of Jenkins or newer one; if you are using newest version it may be that ssh key handling / svn authentication for each job needs to be updated as somewhen in last few months authentication / security handling changed. Best is to look into Jenkins release log.
I'm using Jenkins 1.55x on CentOS installed as RPM; given that it is a webapp I assume Windows 1.4x setup is similar.