In/Out Blocks

_config.yml

@@ -128,6 +128,8 @@ icon-tag:
   galaxy-wf-connection: fa-arrows-h
   galaxy-wf-new: fa-plus
   search: fa fa-search
+  code-in: far fa-keyboard
+  code-out: fas laptop-code
 
   # menus, links
   zenodo_link: fa-files-o

assets/css/main.scss

@@ -36,6 +36,8 @@ $question-color: #8A9AD0;
 $solution-color: #B8C3EA;
 $details-color: $light-gray;
 $feedback-color: #86D486;
+$code-color: #86D486;
+$code-out-color: #fb99d0;
 
 
 @mixin tutorial-box ($bg-color, $color: rgba(255,255,255,.75)) {
@@ -221,6 +223,14 @@ footer {
             @include tutorial-box($question-color, $text-color);
         }
 
+        &.code-in {
+            @include tutorial-box($code-color, $text-color);
+        }
+
+        &.code-out {
+            @include tutorial-box($code-out-color, $text-color);
+        }
+
         &.solution {
             @include tutorial-box($solution-color, $text-color);
         }
@@ -595,3 +605,18 @@ div.supporting_material{
 .alert-heading {
     margin-top: 1rem;
 }
+
+// Code In/Out blocks
+@media (min-width: 1200px) {
+    .code-io{
+        display: flex;
+        flex-direction: row;
+        .code-in {
+            width: 47.5%;
+        }
+        .code-out {
+            margin-left: 5%;
+            width: 47.5%;
+        }
+    }
+}

topics/admin/tutorials/ansible/tutorial.md

@@ -341,18 +341,16 @@ The above introduction was certainly not enough for you to feel confident in Ans
 >     > {: .solution }
 >     {: .question}
 >
-> 11. Run the playbook: `ansible-playbook -i hosts playbook.yml`
+> 11. Run the playbook:
 >
->     > ### {% icon question %} Question
->     >
->     > How does the output look?
+>     > > ### {% icon code-in %} Input: Bash
+>     > > ```bash
+>     > > ansible-playbook -i hosts playbook.yml
+>     > > ```
+>     > {: .code-in}
 >     >
->     > > ### {% icon solution %} Solution
->     > >
->     > > The important thing is `failed=0`
->     > >
+>     > > ### {% icon code-out %} Output: Bash
 >     > > ```
->     > > $ ansible-playbook -i hosts playbook.yml -c local
 >     > > PLAY [my_hosts] ****************************************************************
 >     > > TASK [Gathering Facts] *********************************************************
 >     > > ok: [localhost]
@@ -361,11 +359,8 @@ The above introduction was certainly not enough for you to feel confident in Ans
 >     > > PLAY RECAP *********************************************************************
 >     > > localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
 >     > > ```
->     > >
->     > > You can re-run this and it should say `changed=0`
->     > {: .solution }
->     {: .question}
->
+>     > {: .code-out}
+>     {: .code-io}
 >
 > 12. Login to the appropriate host and `cat /tmp/test.txt` to see that the change was made.
 >
@@ -487,27 +482,26 @@ Templates give you greater control over the files you are deploying to the targe
 >
 > 7. Run the playbook again.
 >
+>
 > 8. Check the contents of `/tmp/test.ini`
 >
->    > ### {% icon question %} Question
->    >
->    > How does it look?
+>    > > ### {% icon code-in %} Input: Bash
+>    > > ```bash
+>    > > cat /tmp/test.ini
+>    > > ```
+>    > {: .code-in}
 >    >
->    > > ### {% icon solution %} Solution
+>    > > ### {% icon code-out %} Output
 >    > >
 >    > > The file should look like:
->    > >
->    > > ```ini
+>    > > ```
 >    > > [example]
 >    > > server_name = Cats!
 >    > > listen = 192.168.0.2
 >    > > ```
->    > >
 >    > > Where the last line has the machine's IP address.
->    > >
->    > {: .solution }
->    >
->    {: .question}
+>    > {: .code-out}
+>    {: .code-io}
 >
 >    Now that this has worked successfully, we will setup a `group_vars` folder
 >    to show how a person using `my-role` would override the `server_name` variable.
@@ -525,35 +519,34 @@ Templates give you greater control over the files you are deploying to the targe
 >
 > 12. Run the playbook again, but imagine you are worried about this change, and supply the `--check --diff` flag to see what changes are made before committing to make them.
 >
->     > ### {% icon question %} Question
->     >
->     > How does the output look?
+>     > ### {% icon code-in %} Input: Bash
+>     > ```bash
+>     > ansible-playbook -i hosts playbook.yml --check --diff
+>     > ```
+>     {: .code-in}
+>
+>     > ### {% icon code-out %} Output
 >     >
->     > > ### {% icon solution %} Solution
->     > >
->     > > ```
->     > > $ ansible-playbook -i hosts playbook.yml --check --diff
->     > > PLAY [my_hosts] ****************************************************************
->     > > TASK [Gathering Facts] *********************************************************
->     > > ok: [localhost]
->     > > TASK [my-role : Copy a file to the remote host] ********************************
->     > > ok: [localhost]
->     > > TASK [my-role : Template the configuration file] *******************************
->     > > --- before: /tmp/test.ini
->     > > +++ after: /home/hxr/.ansible/tmp/ansible-local-1906887dr2u6j8n/tmptx9pdelg/test.ini.j2
->     > > @@ -1,3 +1,3 @@
->     > >  [example]
->     > > -server_name = Cats!
->     > > +server_name = Dogs!
->     > >  listen = 192.168.0.25
->     > > changed: [localhost]
->     > > PLAY RECAP **********************************************
->     > > localhost                  : ok=3    changed=1    unreachable=0    failed=0
->     > > ```
->     > >
->     > > Here you can see that the server_name value will be changed. Despite Ansible reporting `changed=1`, no changes have actually been applied to the system.
->     > {: .solution }
->     {: .question}
+>     > ```
+>     > PLAY [my_hosts] ****************************************************************
+>     > TASK [Gathering Facts] *********************************************************
+>     > ok: [localhost]
+>     > TASK [my-role : Copy a file to the remote host] ********************************
+>     > ok: [localhost]
+>     > TASK [my-role : Template the configuration file] *******************************
+>     > --- before: /tmp/test.ini
+>     > +++ after: /home/hxr/.ansible/tmp/ansible-local-1906887dr2u6j8n/tmptx9pdelg/test.ini.j2
+>     > @@ -1,3 +1,3 @@
+>     >  [example]
+>     > -server_name = Cats!
+>     > +server_name = Dogs!
+>     >  listen = 192.168.0.25
+>     > changed: [localhost]
+>     > PLAY RECAP **********************************************
+>     > localhost                  : ok=3    changed=1    unreachable=0    failed=0
+>     > ```
+>     > Here you can see that the server_name value will be changed. Despite Ansible reporting `changed=1`, no changes have actually been applied to the system.
+>     {: .code-out}
 >
 > 13. Run the playbook again, without the `--check` flag to apply your changes.
 {: .hands_on}
@@ -588,9 +581,25 @@ Now that you've built a small role, you can imagine that building real roles tha
 
 > ### {% icon hands_on %} Hands-on: Installing a module using ansible-galaxy
 >
-> 1. Run the command `ansible-galaxy install -p roles/ geerlingguy.git`
+> 1. Install the geerlingguy.git role with ansible-galaxy into your roles folder:
 >
->    This will install the new role into your `roles` folder, alongside your own role.
+>    > > ### {% icon code-in %} Input: Bash
+>    > > ```bash
+>    > > ansible-galaxy install \
+>    > >     -p roles/ geerlingguy.git
+>    > > ```
+>    > {: .code-in}
+>    >
+>    > > ### {% icon code-out %} Output
+>    > > This will install the new role into your `roles` folder, alongside your own role.
+>    > > ```
+>    > > - downloading role 'git', owned by geerlingguy
+>    > > - downloading role from https://github.com/geerlingguy/ansible-role-git/archive/3.0.0.tar.gz
+>    > > - extracting geerlingguy.git to /tmp/tmp.Jm681gks8d/roles/geerlingguy.git
+>    > > - geerlingguy.git (3.0.0) was installed successfully
+>    > > ```
+>    > {: .code-out}
+>    {: .code-io}
 >
 > 2. Edit your playbook.yml and add the role `geerlingguy.git` at the bottom, after `my-role`
 >
@@ -698,12 +707,13 @@ Now that you have a small role built up, you might start thinking about deployin
 >
 > 8. Check the contents of `/tmp/test.ini`
 >
->    > ### {% icon question %} Question
->    >
->    > How does it look?
+>    > > ### {% icon code-in %} Input: Bash
+>    > > ```bash
+>    > > cat /tmp/test.ini
+>    > > ```
+>    > {: .code-in}
 >    >
->    > > ### {% icon solution %} Solution
->    > >
+>    > > ### {% icon code-out %} Output
 >    > > The file should look like:
 >    > >
 >    > > ```ini
@@ -712,10 +722,8 @@ Now that you have a small role built up, you might start thinking about deployin
 >    > > listen = 192.168.0.2
 >    > > apikey = super-secret-api-key-wow!
 >    > > ```
->    > >
->    > {: .solution }
->    >
->    {: .question}
+>    > {: .code-out}
+>    {: .code-io}
 >
 {: .hands_on}
 

topics/admin/tutorials/cvmfs/tutorial.md

@@ -81,7 +81,6 @@ If the terms "Ansible", "role" and "playbook" mean nothing to you, please checko
 > 1. In your working directory, add the CVMFS role to your `requirements.yml`
 >
 >    ```yaml
->    ---
 >    - src: galaxyproject.cvmfs
 >      version: 0.2.8
 >    ```

topics/contributing/tutorials/create-new-tutorial-content/tutorial.md

@@ -643,6 +643,96 @@ Boxes can be nested, *e.g.* for having tips inside a hands-on:
 ```
 {% endraw %}
 
+## **Code** box
+
+We have added code in/out boxes to help you show commands, and their effects, when running command line commands.
+
+Normally a single column, with the boxes above one another, it will automatically split side-by-side over a given width (1200px);
+
+{% raw %}
+```markdown
+> > ### {% icon code-in %} Input: Bash
+> > ```bash
+> > cat /tmp/test.ini
+> > ```
+> {: .code-in}
+>
+> > ### {% icon code-out %} Output
+> > The file should look like:
+> >
+> > ```ini
+> > [example]
+> > server_name = Dogs!
+> > listen = 192.168.0.2
+> > apikey = super-secret-api-key-wow!
+> > ```
+> {: .code-out}
+{: .code-io}
+```
+{% endraw %}
+
+Rendered (try it! resize your browser)
+
+> > ### {% icon code-in %} Input: Bash
+> > ```bash
+> > cat /tmp/test.ini
+> > ```
+> {: .code-in}
+>
+> > ### {% icon code-out %} Output
+> > The file should look like:
+> >
+> > ```ini
+> > [example]
+> > server_name = Dogs!
+> > listen = 192.168.0.2
+> > apikey = super-secret-api-key-wow!
+> > ```
+> {: .code-out}
+{: .code-io}
+
+If you leave off the `{: .code-io}`, it will render as a single column always.
+
+{% raw %}
+```markdown
+> ### {% icon code-in %} Input: Bash
+> ```bash
+> cat /tmp/test.ini
+> ```
+{: .code-in}
+
+> ### {% icon code-out %} Output
+> The file should look like:
+>
+> ```ini
+> [example]
+> server_name = Dogs!
+> listen = 192.168.0.2
+> apikey = super-secret-api-key-wow!
+> ```
+{: .code-out}
+```
+{% endraw %}
+
+Rendered:
+
+> ### {% icon code-in %} Input: Bash
+> ```bash
+> cat /tmp/test.ini
+> ```
+{: .code-in}
+
+> ### {% icon code-out %} Output
+> The file should look like:
+>
+> ```ini
+> [example]
+> server_name = Dogs!
+> listen = 192.168.0.2
+> apikey = super-secret-api-key-wow!
+> ```
+{: .code-out}
+
 # Citations
 If you would like to cite any articles, books or websites in your tutorial, you can do so by adding a file called `tutorial.bib` next to your `tutorial.md` file. In this file you may enter [bibtex](http://www.bibtex.org/Using/) formatted citations. An example is given below: