I'm upgrading a Sinatra ("classic" style) app to latest released version, from 1.3.3 to 1.4.6. I also use config_file from sinatra-contrib (also upgraded from 1.3.2 to 1.4.6) with multi-environments.
My config file (config/app.yml) looks like:
development: &defaults
console_username: admin
console_password: secret
test:
<<: *defaults
staging:
<<: *defaults
production:
<<: *defaults
On the other hand, I have some POROs under lib/. Before the upgrade, I can access to the settings inside those classes under lib/, but now I can't. In summary, previously I can do something like:
settings.console_username
After the upgrade, I need to access these variables by:
Sinatra::Application.console_username
I reviewed the changelog but I can't find this change documented, am I missing something?
PS: I also found this: Access Sinatra settings from a model. I'm agree with the last answer, probably is a better idea to decouple this thing, and pass the settings to the class.
Related
After changing an asset (a css or js) file I see in the logs that the change was noticed and compiled, and the browser also auto-reloads.
[debug] Live reload: priv/static/js/app.js
10:53:15 - info: compiled MyComponent.jsx and 2095 cached files into 2
files in 2.3 sec
However, it doesn't appear that the assets in /priv/static were actually updated. I can only see my change in the browser once I run mix phx.digest, and hard refresh the browser.
Any ideas on how to troubleshoot this?
Using:
Phoenix 1.3
brunch 2.10.7
config/dev.exs:
config :my_app, MyApp.Web.Endpoint,
http: [port: 4000],
debug_errors: true,
code_reloader: true,
check_origin: false,
watchers: [node: ["node_modules/brunch/bin/brunch", "watch", "--stdin",
cd: Path.expand("../assets", __DIR__)]]
# Watch static and templates for browser reloading.
config :my_app, MyApp.Web.Endpoint,
live_reload: [
patterns: [
~r{priv/static/.*(js|css|png|jpeg|jpg|gif|svg)$},
~r{priv/gettext/.*(po)$},
~r{lib/my_app/web/views/.*(ex)$},
~r{lib/my_app/web/templates/.*(eex)$}
]
]
TL;DR — If you don't set the cache_static_manifest setting on your endpoint, it won't generate versioned URLs.
So, I know I'm about three years late here, but I recently figured this out. I discovered that merely setting the cache_static_manifest value in the Endpoint config will cause it to use the digest in any mode. (This is documented, but not in a way that seemed particularly clear to me.)
Now, you might be thinking "But I didn't set that in dev mode." I thought that, too, until I realized that I had written a naive config/runtime.exs.
At the time, I had been focused on configuring things a runtime when running a release, but completely forgot that it configures things even when not running in a release. Once I made it conditional, everything was fine.
Example:
if Config.config_env == :production do
config :my_app, MyAppWeb.Endpoint, cache_static_manifest: "priv/static/cache_manifest.json"
end
I ran into the same issue and for me it helped to manually remove the static folder with rm -rf priv/static and to restart the server with mix phx.server. Afterwards the hot reloading worked without having to manually run mix phx.digest all the time.
Another possible cause is that the Endpoint module (lib/my_app_web/endpoint.ex) is setting Plug.Static to use compressed assets:
defmodule MyAppWeb.Endpoint do
use Phoenix.Endpoint, otp_app: :my_app_web
plug Plug.Static,
# ...
gzip: true,
Then, if a release has been built from within the project directory and the gzipped assets are still present when developing, they will be served instead of the newly-saved, non-compressed assets.
To avoid this:
config/dev.exs:
config :my_app, :environment, :dev
config/test.exs:
config :my_app, :environment, :test
config/prod.exs:
config :my_app, :environment, :prod
lib/my_app_web/endpoint.ex:
defmodule MyAppWeb.Endpoint do
use Phoenix.Endpoint, otp_app: :my_app_web
in_prod = Application.get_env(:my_app, :environment) == :prod
plug Plug.Static,
# ...
gzip: in_prod,
I setup a Jekyll blog on Github-Pages 5 months ago. It was working at that time, and I though it would be a nice place to post things.
Long story short, I wrote a first post, but then I never used, until yesterday when I wanted to check that all was working fine, but it was not. I also could not run Jekyll locally.
I do not use ruby on my daily basis ,so they were outdated. I though maybe if I update it and generate the site again everything is going to be working fine.
I updated ruby from 2.1.2 to 2.2.1, and I tried other things to make it work. Now is working locally, but throwing this
Generating...
Defaults: An invalid front-matter default set was found:
[{"scope"=>{"path"=>"_posts/"}, "values"=>{"author"=>"Agustin Gambina"}}]
Defaults: An invalid front-matter default set was found:
[{"scope"=>{"path"=>"_posts/"}, "values"=>{"author"=>"Agustin Gambina"}}]
I also added a Gemfile to the root directory
source 'https://rubygems.org'
require 'json'
require 'open-uri'
versions = JSON.parse(open('https://pages.github.com/versions.json').read)
gem 'github-pages', versions['github-pages']
When I run
github-pages health-check
I get this
Checking domain littlebit.me...
Uh oh. Looks like something's fishy: Domain does not resolve to the GitHub Pages server
Does anyone know why it happened to me that is not working anymore? was because it was outdated and something changed?
thank you
You have an error in your _config.yml file :
-
-
scope:
path: "_posts/scala"
values:
author: Agustin Gambina
Must be :
-
scope:
path: "_posts/scala"
values:
author: Agustin Gambina
This is not a fatal error, so your site build, but your rule is not applied.
Concerning the health-check, it works for me as it checks littlebit.me that resolve to github IPs.
$: dig littlebit.me
...
littlebit.me. 1800 IN A 192.30.252.154
littlebit.me. 1800 IN A 192.30.252.153
If it doesn't work on your PC, you may have a DNS problem. Maybe you've set a bad value in your hosts file ?
I don't understand why the deployment is not working. I'm getting the following error in the build console:
Preparing deploy
Found gem
/usr/lib/git-core/git-stash: 186: /usr/lib/git-core/git-stash: cannot create /home/travis/build/prismicio/ruby-kit/.git/logs/refs/stash: Directory nonexistent
Build: https://travis-ci.org/prismicio/ruby-kit/jobs/40767391
My .travis.yml:
language: ruby
rvm:
- 2.1.1
- 2.1.0
- 2.0.0
- 1.9.3
- 1.9.2
- jruby-19mode
script: bundle exec rspec spec
notifications:
email:
- example#example.com
addons:
code_climate:
repo_token: X
deploy:
provider: rubygems
api_key:
secure: XXX
gemspec: prismic.gemspec
on:
tags: true
all_branches: true
What's wrong with the build?
The error:
/usr/lib/git-core/git-stash: 186: /usr/lib/git-core/git-stash: cannot create /home/travis/build/prismicio/ruby-kit/.git/logs/refs/stash: Directory nonexistent
may be related to how you're deploying your files to your provider and it's triggered by git stash and its DPL::Provider#cleanup process (see: releases.rb). By default Deployment Provider will deploy the files from the latest commit. This is not supported for all providers, therefore this just means that the "releases" provider needs to skip the cleanup, so it should deploy from the current file state instead (see #BanzaiMan comment) by adding this line:
skip_cleanup: true
This is because every provider has slightly different flags and these are documented in the Deployment section (or for the latest documentation check on GitHub for supported providers).
Further more, the above error is basically related to Travis CI bug (GH #1648) where basically File#basename is stripping the directory part (as per #BanzaiMan comment) and it's not clear why this cannot manifest in the CLI case. So this is something to fix in the near future.
I've just switched to using the Figaro gem v1.0.0 with Rails 4.1.6.
Since deleting my secrets.yml file I now get the error:
Unexpected error while processing request: Missing secret_key_base for 'development' environment, set this value in config/secrets.yml
Do i still need the secrets.yml file - isn't this the job of Figaro's application.yml file?
My application.yml file is like
development:
secret_key_base: 56....
Looking into the Railties gem at https://github.com/rails/rails/blob/master/railties/lib/rails/application.rb you can see the secrets method defined which includes a fallback for secret_key_base
def secrets #:nodoc:
#secrets ||= begin
secrets = ActiveSupport::OrderedOptions.new
yaml = config.paths["config/secrets"].first
if File.exist?(yaml)
require "erb"
all_secrets = YAML.load(ERB.new(IO.read(yaml)).result) || {}
env_secrets = all_secrets[Rails.env]
secrets.merge!(env_secrets.symbolize_keys) if env_secrets
end
# Fallback to config.secret_key_base if secrets.secret_key_base isn't set
secrets.secret_key_base ||= config.secret_key_base
secrets
end
end
In config/application.rb adding the following resolves the issue
config.secret_key_base = Figaro.env.secret_key_base
I have never used Figaro gem but try these, create the config/secret.yml file and inside write:
development:
secret_key_base: <%= ENV['secret_key_base'] %>
I was just informed that as of Rails 4.1.x, config/secrets.yml does need to be uploaded to heroku. Rails will no longer look directly at its ENV in order to find its secret_key_base.
So secrets.yml needs to come off of the .gitignore file, and your project would need to be recommited and re-pushed to heroku.
(secrets.yml would still get its values from heroku's ENV, which would still be loaded up via Figaro the same way as before - figaro heroku:set -e production. Use heroku config to get a nice quick look at your ENV variables to confirm they are there)
I have a modular Sinatra app using Sinatra::ConfigFile and have broken out my settings into a yaml file so I can modify paths/urls when in different environments.
As a basic example, I have:
development:
url_root: 'http://127.0.0.1:9292'
production:
url_root: 'http://domain.com'
However, settings.url_root does not work (undefined method 'url_root') unless I pull it out of the nested environment block. Checking my environment: p ENV['RACK_ENV'] returns development.
I am using Sinatra 1.4.5, sinatra-contrib 1.4.2
What am I doing wrong?
OK, well it turns out it was a misunderstanding of, what I believe, is a slightly confusingly worded documentation on the Sintara page which states:
But it also can provide specific environment configuration. There are
two ways to do that: at the file level and at the setting level. They
are illustrated, repsectively, as follows:
development:
foo: development
bar: bar
test:
foo: test
bar: bar
production:
foo: production
bar: bar
and
foo:
development: development
test: test
production: production
bar: bar
So, when using a settings yaml file with Sinatra, you want to define the variable name and then nest the environments within it (not the other way around), and the working format for my question above is:
url_root:
development: 'http://127.0.0.1:9292'
production: 'http://domain.com'