Syntax issues commonly trip up beginners, and so there are a few basic recommendations I have: You're welcome! And I'm so glad you're finding my work helpful in learning your new skill. If you could give me a tip or two about this it would help a lot. I modify something in the playbook (add or remove some spaces) then I execute the playbook in the terminal and so on.

One of the most common/often problems that I encounter after I write a playbook and execute it is the Syntax error and it is mainly caused by indentation meaning I either have too many spaces or none after which I spend a lot of time trying to figure out how to align everything with proper spacing, mostly it's a trial and error process.

I have recently started going into Ansible because I lost my job and wanted to learn a new skill or at least build the foundation as learning Ansible is an ongoing process.įor people like me who do not have prior programming experience it would be good if you could please give a tip or two about how to set up a common text editor like e.g VSCode or whatever it is that you use, what plugins to use which are helpful when writing playbooks. In these harsh times we are living you are doing a great thing by teaching Ansible and essentially helping people gaining a new skill. I want to start by thanking you for what you are doing. Nothing's worse than debugging a complicated role and having to visually parse through three different YAML styles! I would encourage the use of one of these styles as a general rule, though, and also communicate as much to the people who will be working with you on your playbooks. As with most programming and technical things, being consistent is more important than following a particular set of rules, especially if that set of rules isn't universally agreed upon. If you prefer to use a different syntax or conventions, that's not wrong. I have chosen to use the shorthand syntax for simpler tasks, and structured maps for more complex tasks, since they feel more maintainable and readable to my eye. SummaryĪs I mentioned in the mailing list, one of Ansible's strengths is its flexibility any one of the above methods of task definition is equally valid and functional.

Typically, if you can find a way to run a command without having to use creates and chdir, or very long commands (which are arguably unreadable either in single or multiline format!), it's better to do that instead of this monstrosity.īut sometimes the above is as good as you can do to keep unweildy tasks sane.

Translated_yaml = /sites/default/settings.php

Simple things miguel tabs