Setup Capistrano in prod env: which repo to checkout?

[jpprost]

Hi,

about setting up capistrano, the current installer's README states that:

Checkout the latest stable version:
git checkout origin/2.1.1 -b stable

Which repo are we talking about: my own fork of consuldemocracy/consuldemocracy?

If I run the command from the local repo of my fork I get the error message
fatal: 'origin/2.1.1' is not a commit and a branch 'stable' cannot be created from it

Unfortunately, this step in the installer's README, and a few other ones, differ significantly from the video about setting up capistrano and the README files it refers to: should the steps related the capistrano branch be followed? They are no longer listed in the current README, and the video seems to skip them.

I'm confused, sorry.

Cheers,
JP

[javierm]

Hi, @jpprost 😄.

Everything in the "Deploys with Capistrano" section refers to your fork of consuldemocracy/consuldemocracy.

Unfortunately, the video is indeed outdated. Maybe we should remove the link to the video until we update it 🤔.

fatal: 'origin/2.1.1' is not a commit and a branch 'stable' cannot be created from it

Looks like your local repository doesn't have the same tags as the main repository 🤔. Try git fetch origin --tags, and run the mentioned git checkout command again. If you still get the error, add the main repository with git remote add upstream [email protected]:consuldemocracy/consuldemocracy.git and then try git fetch upstream --tags before once again running the mentioned git checkout command.

If one of the steps above works, maybe you could open a pull request to change the installer's README?

[javierm]

Sorry, my bad!

Instead of git checkout origin/2.1.1 -b stable, the right command seems to be git checkout 2.1.1 -b stable.

[jpprost]

Everything in the "Deploys with Capistrano" section refers to your fork of consuldemocracy/consuldemocracy.

Ok, good.

Looks like your local repository doesn't have the same tags as the main repository 🤔. Try git fetch origin --tags, and run the mentioned git checkout command again.

No luck, I'm afraid.

add the main repository with git remote add upstream [email protected]:consuldemocracy/consuldemocracy.git and then try git fetch upstream --tags before once again running the mentioned git checkout command.

Ok, now it works. Thanks :-) EDIT: at the time, I did not try to run the server. See next comment for more details.

But it means that I had to restore the files that we modified while debugging: app/assets/stylesheets/foundation_and_overrides.scss and package-lock.json

If one of the steps above works, maybe you could open a pull request to change the installer's README?

Sure. I'll do that.

[jpprost]

As I try to start the server again (I was going through the Capistrano setup procedure with the dev server offline) in order to check the changes I made to a view (following instructions):

Could not find rails-6.1.7.7, acts-as-taggable-on-9.0.1, ahoy_matey-4.2.1, airbrake-13.0.3, audited-5.4.0, autoprefixer-rails-8.2.0, caxlsx-3.4.1, dalli-3.2.6, delayed_job_active_record-4.1.7, devise-4.9.2, exiftool_vendored-12.60.0, foundation-rails-6.6.2.0, globalize-6.2.1, graphql-1.12.14, initialjs-rails-0.2.0.9, invisible_captcha-2.1.0, jquery-fileupload-rails-1.0.0, omniauth-2.1.1, paranoia-2.6.2, pg-1.4.3, responders-3.1.0, savon-2.14.0, wicked_pdf-2.7.0, byebug-11.1.3, faker-3.2.3, knapsack_pro-5.7.0, spring-2.1.1, spring-commands-rspec-1.0.4, rspec-rails-5.1.2, capistrano-3.17.3, pronto-0.11.1, pronto-scss-0.11.0, rubocop-1.56.4, rubocop-performance-1.19.1, scss_lint-0.60.0, actioncable-6.1.7.7, actionmailbox-6.1.7.7, actionmailer-6.1.7.7, actionpack-6.1.7.7, actiontext-6.1.7.7, actionview-6.1.7.7, activejob-6.1.7.7, activemodel-6.1.7.7, activerecord-6.1.7.7, activestorage-6.1.7.7, activesupport-6.1.7.7, railties-6.1.7.7, sprockets-rails-3.2.2, device_detector-1.1.1, airbrake-ruby-6.2.0, request_store-1.5.1, marcel-1.0.2, nokogiri-1.16.2, delayed_job-4.1.10, bcrypt-3.1.19, exiftool-1.2.4, sass-3.7.4, sprockets-es6-0.9.2, rack-2.2.8.1, rack-protection-3.1.0, akami-1.3.1, httpi-2.5.0, nori-2.6.0, wasabi-3.7.0, i18n-1.14.1, rails-i18n-6.0.0, rexml-3.2.6, rspec-core-3.11.0, rspec-expectations-3.11.0, rspec-mocks-3.11.1, rspec-support-3.11.0, airbrussh-1.4.2, sshkit-1.21.5, better_html-2.0.2, octokit-6.1.1, rubocop-ast-1.31.1, minitest-5.22.2, rbtree3-0.7.0, mini_portile2-2.8.5, sass-listen-4.0.0, babel-source-5.8.35, babel-transpiler-0.7.0, faraday-2.7.10, net-smtp-0.4.0.1, socksify-1.7.1, diff-lcs-1.5.0, net-ssh-7.2.0, rb-fsevent-0.11.2, rb-inotify-0.10.1, faraday-net_http-3.0.2 in locally installed gems nor rails-assets-markdown-it-9.0.1 in locally installed gems
Run `bundle install --gemfile /home/prost/LaREC/consuldemocracy/Gemfile` to install missing gems.

If I run the command above, I get the following introductory message:

Bundler 2.4.19 is running, but your lockfile was generated with 2.3.26. Installing Bundler 2.3.26 and restarting using that version.

then it goes on with the installation, until the following post-install message:

Post-install message from devise:

[DEVISE] Please review the [changelog] and [upgrade guide] for more info on Hotwire / Turbo integration.

  [changelog] https://github.com/heartcombo/devise/blob/main/CHANGELOG.md
  [upgrade guide] https://github.com/heartcombo/devise/wiki/How-To:-Upgrade-to-Devise-4.9.0-%5BHotwire-Turbo-integration%5D
  Post-install message from sass:

Ruby Sass has reached end-of-life and should no longer be used.

* If you use Sass as a command-line tool, we recommend using Dart Sass, the new
  primary implementation: https://sass-lang.com/install

* If you use Sass as a plug-in for a Ruby web framework, we recommend using the
  sassc gem: https://github.com/sass/sassc-ruby#readme

* For more details, please refer to the Sass blog:
  https://sass-lang.com/blog/posts/7828841

1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details

Running the server still fails, with the following message:

/usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:43:in `include': Refinement#include has been removed (TypeError)

        include Methods
                ^^^^^^^
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:43:in `block (2 levels) in <module:DeprecatedDSL>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:42:in `refine'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:42:in `block in <module:DeprecatedDSL>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:41:in `each'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:41:in `<module:DeprecatedDSL>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:15:in `<module:GraphQL>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql/deprecated_dsl.rb:2:in `<top (required)>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `block in require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:299:in `load_dependency'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/graphql-1.12.14/lib/graphql.rb:149:in `<top (required)>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:60:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:60:in `block (2 levels) in require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:55:in `each'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:55:in `block in require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:44:in `each'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler/runtime.rb:44:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/bundler-2.3.26/lib/bundler.rb:186:in `require'
	from /home/prost/LaREC/consuldemocracy/config/application.rb:20:in `<top (required)>'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `block in require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:299:in `load_dependency'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/activesupport-6.1.7.7/lib/active_support/dependencies.rb:332:in `require'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/railties-6.1.7.7/lib/rails/commands/server/server_command.rb:138:in `block in perform'
	from <internal:kernel>:90:in `tap'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/railties-6.1.7.7/lib/rails/commands/server/server_command.rb:135:in `perform'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/thor-1.3.1/lib/thor/command.rb:28:in `run'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/thor-1.3.1/lib/thor/invocation.rb:127:in `invoke_command'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/thor-1.3.1/lib/thor.rb:527:in `dispatch'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/railties-6.1.7.7/lib/rails/command/base.rb:69:in `perform'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/railties-6.1.7.7/lib/rails/command.rb:48:in `invoke'
	from /usr/share/rvm/gems/ruby-3.2.3/gems/railties-6.1.7.7/lib/rails/commands.rb:18:in `<top (required)>'
	from bin/rails:4:in `require'
	from bin/rails:4:in `<main>'

At this stage, my guess was that the problem might come from the files that were restored to their state in the main repo (see previous comment). For reference sake, my locally modified version of foundation_and_overrides.scss was coming from the following action:

One more thing to try: in the app/assets/stylesheets/foundation_and_overrides.scss file, comment (don't delete, so line numbers remain the same) lines 10, 49 and 50 (which are the lines referencing motion-ui. Then try to recompile the assets again and paste the error message (if you get one) to see whether the error trace is slightly different or remains the same.

Originally posted by @javierm in #5490 (comment)

But since the error message here is different, I am not sure that I should reproduce the fix you suggested at the time (i.e., commenting out the lines referencing motion-ui). Or should I?

Any other suggestion?

Cheers :-)

[javierm]

The error message mentions Ruby 3.2.3, and Consul Democracy 2.1.1 uses Ruby 3.1.4, so my best guess is that, when using RVM, you have to run cd to a different folder and then back to the application folder when checking out branches that use a different Ruby version, or run rvm use in order to use the one in .ruby-version. That's the main reason why I use rbenv, which unfortunately you couldn't install properly IIRC.

There will probably be a solution for this issue in the future, planned for Consul Democracy 2.3.0, which consists in adding ruby file: ".ruby-version" to the Gemfile. We need to properly test it first, though.

[javierm]

I had to restore the files that we modified while debugging: app/assets/stylesheets/foundation_and_overrides.scss and package-lock.json

Restoring the original files is the right option 👍; I suggested them for debugging purposes, but once we found out that the problem was using a different version of Node.js and NPM, they're no longer needed.

[H-Hp]

Based on the information you provided, it seems that the instructions you're referring to are related to setting up Capistrano for the deployment process of the ConsuDemocracy project.

The command git checkout origin/2.1.1 -b stable is intended to create a new branch called stable from the remote branch origin/2.1.1, which is likely a specific version or release tag in the official ConsuDemocracy repository.

Since you're working with your own fork of the consuldemocracy/consuldemocracy repository, the origin remote points to your forked repository on GitHub, which may not have the 2.1.1 branch or tag.

If you're setting up Capistrano for your fork, you should follow the instructions specific to your fork's repository and the current state of the project. The steps listed in the installer's README or the video you mentioned may be outdated or tailored for the official repository.

Here's what you can do:

1. Check the available branches/tags: Run git branch -a to list all available branches, including remote branches. If you see a branch or tag named 2.1.1 or something similar, you can try checking it out using git checkout 2.1.1.

2. Use the main/master branch: If there's no specific branch or tag mentioned for setting up Capistrano, you can proceed with the instructions using the main branch (usually master or main) of your forked repository.

3. Refer to the official project documentation: If the instructions in your fork's README or the video you mentioned are outdated or unclear, you can refer to the official ConsuDemocracy project documentation or seek help from their support channels (if available) for the most up-to-date instructions on setting up Capistrano.

4. Adjust the instructions accordingly: If the instructions involve checking out a specific branch or tag, adjust the commands to match the branches or tags available in your forked repository.

It's essential to ensure that you're following the correct instructions for your project's current state and repository structure. If you're still facing issues, you may need to consult the project maintainers or seek further assistance from the community or support channels.

[jpprost]

@H-Hp Completely useless, I'm afraid...

[javierm]

@jpprost The answer seems to be generated by an AI 🤔.

[jpprost]

it crossed my mind too, yes.

[jpprost]

Hi @javierm!

The error message mentions Ruby 3.2.3, and Consul Democracy 2.1.1 uses Ruby 3.1.4, so my best guess is that, when using RVM, you have to run cd to a different folder and then back to the application folder when checking out branches that use a different Ruby version, or run rvm use in order to use the one in .ruby-version.

I'm afraid I do not quite understand what you mean about changing folders back and forth.
But here's what I ran, from my main consuldemocracy folder, on the stable branch:

rvm install "ruby-3.1.4"
rvm use 3.1.4
bundle install

Then I could start the localhost server again, and see the changes I made (note that for some reason the page took maybe 30-ish seconds to load up, but eventually it did).

That's the main reason why I use rbenv, which unfortunately you couldn't install properly IIRC.

I can try again, but since I installed the server using rvm what kind of side-effects could I have to face if I change now?

At some point I might try again from scratch to install a dev server, going through all our notes, and suggest amends to the README in order to tackle everything we went through.

There will probably be a solution for this issue in the future, planned for Consul Democracy 2.3.0, which consists in adding ruby file: ".ruby-version" to the Gemfile. We need to properly test it first, though.

[javierm]

I'm afraid I do not quite understand what you mean about changing folders back and forth.

I meant something like

cd ..
cd consuldemocracy

Since RVM detects the Ruby version when entering a folder IIRC.

But never mind, using rvm use works just fine 👍.

for some reason the page took maybe 30-ish seconds to load up, but eventually it did

The first request after starting the server is usually slow, since Rails is loading the application and automatically generating assets-related data in the tmp/cache folder.

I can try again, but since I installed the server using rvm what kind of side-effects could I have to face if I change now?

Trying it is up to you; some people prefer RVM, although they have to remember to run rvm use when switching branches 😌. Regarding side-effects on a production server, luckily, AFAIK there are zero side-effects 😄. Keep using RVM on production, since it's the only version manager that's supported by our Capistrano configuration.