mastodon@animusvox:~/live$ gem install bundler -v 1.16.6
Fetching: bundler-1.16.6.gem (100%)
Successfully installed bundler-1.16.6
Parsing documentation for bundler-1.16.6
Installing ri documentation for bundler-1.16.6
Done installing documentation for bundler after 4 seconds
1 gem installed
mastodon@animusvox:~/live$ bundle
Fetching gem metadata from^Cmastodon@anim$ ^C


why is there a Gemfile.lock file in here with that?

- name: Install bundler
shell: cd /home/mastodon/live && gem install bundler && gem install bundler -v 1.16.6

I just did this and that fixed the playbook 🙄

apparently certbot was broken in this Mastodon playbook too so I just fucking replaced it with since I like that more than certbot

PLAY RECAP : ok=44 changed=21 unreachable=0 failed=0

hours later of fixing and re-working this playbook, we have success

I'm gonna go get some lunch


my Mastodon Ansible playbook is here

its pretty fucking good if I do say so myself

go test it out, if its broken somewhere, let me know so I can fix it, thanks

also updated Mastible to automatically checkout the latest stable Mastodon version automatically instead of me updating the version manually

the relevant lines, using Ansible register variable functionality to my advantage

@staticsafe From a quick glance, my main advice would be to use variables and blocks to avoid repeating yourself so much, and to use chdir with command instead of `shell: chdir foo && cmd` (if running this under bash is important, you can move the chdir to args and keep shell.) E.g. here's a rewrite of roles/mastodon-config/tasks/install.yml: (I'd really move those variables outside this file entirely, but this shows the principle.)

@staticsafe Mainly because it doesn't require a shell; secondarily, because it's less cognitive load to read what the tasks are doing. When you have a task like 'shell: cd /home/mastodon/live && bundle exec rake secret' your brain has to do more parsing to find the actual command than with 'shell: bundle exec rake secret', and it makes scanning through the tasks quickly more of a burden.

I think the question was why you typed chdir instead of cd.

@loke Because the module argument is `chdir`, not `cd`. Using `cd` as a module argument would be invalid.

@loke @flowerysong chdir is its own binary as opposed to cd which is part of the Bash shell, hence chdir not requiring a shell

@staticsafe @loke Oh, I see, there was a typo in my first post. I meant to say "shell: cd foo" and I said "shell: chdir foo". Oh, the embarrassment. I shall tear my clothes and wear sackcloth henceforth.

If chdir is its own binary, it can't do anything useful. The current directory is local to its processes and children, so if yiu create a binary that simply runs the chdir system call, it cannot affect the current directory of the calling process.

However, scrolling back in the thread it seems this is not actually shellscript, so I'm guessing this is actually an embedded command in the framework in which this is run?

Sign in to participate in the conversation

staticsafe's personal Mastodon instance.