In deploy.rb, I believe that :rails_env is typically set by require 'capistrano/rails' found in your Capfile. I am using rails, but not using the built in asset pipeline and therefore, don't use capistrano/rails and was in the predicament of having to manually set :rails_env in deploy.rb when switching between staging and production deploys. This seemed rather silly as the environment is always included when executing cap staging deploy or cap production deploy. I am posting this question, as it seems like it could be a fairly common pain point with a trivial solution, but after much googling, I came up empty-handed. I therefore dug into the Capistrano 3.1.0 source code to figure out how to access the stage variable entered on the command line and will follow up with a brief answer that does a bit of explaining.
The simple answer is to add the following line near the top of deploy.rb:
set :rails_env, fetch(:stage)
The variable :stage gets set in capistrano/setup which is required in your Capfile. This script creates rake tasks for each stage that is defined in config/deploy. Inside the definition for the rake task you will find the following: set(:stage, stage.to_sym) which is the stage/rails_env variable from your cap staging deploy or cap production deploy command.
Related
I am configuring an SPI provider (specifically, for the x509cert-lookup SPI) in Keycloak, deployed on bare metal. The provider config documentation tells me to use the build command for selecting the provider and the start command to pass options to that provider.
However, from the docs about general configuration I conclude that all options can also be passed in a keycloak.conf file, and the build step is merely an optimization.
If I do not care much about optimizing startup time: Can the build step be eliminated altogether, putting all options into the config file for simplicity? Or is there anything so special about the providers that they must be set in the build step?
(Background: I am running a non-containerized bare metal setup where Keycloak is managed by systemd, and we've had situations where provider configuration was somehow lost between restarts.)
You're right when you mention that the extra build step prior to the start command is purely optimization.In fact, when you call start, it performs a build!
When running inside a containerized environment, the optimization step is a nice feature. Here's the configs that can be set in the extra build step (if desired)
https://www.keycloak.org/server/all-config?f=build
If it's not the case, like you, and you run on bare metal, then the additional build doesn't provide you much.
Here's the most useful link to get you started:
https://www.keycloak.org/server/configuration
Beware that there is an order of precedence when setting the config such as:
command-line parameters
environment variables
user-created .conf file
keycloak.conf file located in the conf directory.
command-line parameters take precedence over environment (and so on).
Hope this helps!
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
Please note, although my specific example here involves Java/Grails, it really applies to any type of task available in Bamboo.
I have a task that is a part of a Bamboo build where I run a Java/Grails app like so:
grails run-app -Dgrails.env=<ENV>
Where "<ENV>" can be one of several values (dev, prod, staging, etc.). It would be nice to "parameterize" the plan so that, sometimes, it runs like so:
grails run-app -Dgrails.env=dev
And other times, it runs like so:
grails run-app -Dgrails.env=staging
etc. Is this possible, if so, how? And does the REST API allow me to specify parameter info so I can kick off different-parameterized builds using cURL or wget?
This seems to be a work around but I believe it can help resolve your issue. Atlassian has a free plugin call Bamboo Inject Variables Plugin. Basically, with this plugin, you can create an "Inject Bamboo Variables from file" task to read a variable from a file.
So the idea here is to have your script set the variable to a specific file then kick off the build; the build itself will read that variable from the file and use it in the grails task.
UPDATE
After a search, I found that you can use REST API to change plan variables (NOT global). This would make your task simpler: just define a plan variable (in Plan Configuration -> tab Variables) then change it every time you need to. The information on how to change is available at Bamboo Knowledge Base
In Capistrano v2, I can run deploy on the server specified in the command-line.
cap staging HOSTS="host1,host2" deploy
How can I do the same thing in the Capistrano v3?
example scenario
I have to scale my app, but I don't want to deploy all of my app servers. So I just want to run deploy on the new one.
Not sure if you found this or not but the documentation says you can just list it in the command line like this:
cap --hosts=server1,server2 production deploy
See documentation here:
Host Filtering Docs
See code here:
Code Filtering Link
Looking at the code, it appears to be able to accepts HOSTS also.
See test confirming this:
Test Confirming Both Options
I'm attempting to deploy to a server via Capistrano and I keep getting the error the task `staging:symlink' does not exist.
I've run cap:deploy setup and cap deploy successfully getting the releases and shared directories created but the above error always shows at the end and I think it's stopping my code from getting moved to the root of the directory where it belongs.
I'm new at using Capistrano and I've Googled the issue but I cannot find anything that helps. I can include my code and everything I just don't know what to show to help... let me know!
Thanks for any help you can provide!
The built-in symlink task for capistrano 2.x is cap deploy:symlink.
staging:symlink is not a valid task, unless you've defined it yourself. If you're not defining this, you are accidentally calling it somewhere in your config files (deploy.rb or one of your staging config files, if you're using multistage).
Additionally, deploy:symlink should be called automatically as part of the deploy task. You don't need to call it manually.