|
| 1 | +# Workflow Docs |
| 2 | + |
| 3 | +## Tmate action |
| 4 | + |
| 5 | +The following is a rundown of the tmate action used in most of the workflows. Its structure looks something like this: |
| 6 | + |
| 7 | +```github-action |
| 8 | + - name: Setup tmate session |
| 9 | + if: ${{ failure() }} |
| 10 | + |
| 11 | + timeout-minutes: 15 |
| 12 | + with: |
| 13 | + detached: false |
| 14 | + limit-access-to-actor: true |
| 15 | +``` |
| 16 | + |
| 17 | +While it may seem obvious to some, it is important to note that the workflow will not complete until the tmate action step completes. |
| 18 | +Since we have concurrency set on most of our workflows, this means that if you push another run of the workflow, you must first close your SSH session. |
| 19 | +More information on this is available in the following section [When / Why does the action step close](./README.md#when--why-does-the-action-step-close). |
| 20 | +It is for this reason that this may not be useful in every situation. |
| 21 | + |
| 22 | +### When / Why does the action step close? |
| 23 | + |
| 24 | +This action will wait for one of two cases, the first of which is connection close. The SSH session only supports a single connection, |
| 25 | +if you ssh and close the connection the action step will close and the workflow will proceed, even if you have not finished the `timeout-minutes` window. |
| 26 | +Note also that as it only supports a single connection, only one person can ssh to the tmate sessions, others will be rejected. |
| 27 | +The second condition is that the `timeout-minutes` elapse, in which case the action will boot you out of ssh, the session will close and the worfklow will continue. |
| 28 | + |
| 29 | +### Configurations |
| 30 | + |
| 31 | +The key values are `timeout-minutes`, `detached` and `limit-access-to-actor`. |
| 32 | + |
| 33 | +#### Detached mode |
| 34 | + |
| 35 | +If the action step is ran with `detached: true`, it will proceed to the next action steps unhindered. |
| 36 | +If the workflow finishes before the `timeout-minutes` has elapsed, it will pop open a new action step at the end of the workflow to wait for and cleanup the tmate action. |
| 37 | +If the step is instead ran with `detached: false` the workflow will not proceed until the step closes. |
| 38 | + |
| 39 | +#### Limit access to actor |
| 40 | + |
| 41 | +With `limit-access-to-actor` set to `true`, the action look who created the PR, and grab the public SSH keys stored in their Github account. |
| 42 | +It will reject connections from any SSH private key that does not match the public key listed in the Github account. |
| 43 | +This is recommended, as it prevents others from abusing your runners, but may be dissabled to allow a teamate to ssh instead. |
| 44 | + |
| 45 | +### How does this action step work with Terraform / EC2 instances? |
| 46 | + |
| 47 | +This is a great question! Its important to know that there are 2 parrallel tracks of CI in this example, the first being Github actions + the Runner, |
| 48 | +and the second being Ansible playbooks, ran on the runner but SSH to an EC2 instance. Imagine that our workflow starts with Github actions, |
| 49 | +which then calls the ansible playbook and does some stuff on our EC2 over ssh. Imagine then we get to something we want to debug, |
| 50 | +and we open a `deteached` SSH session. Since it is detached the workflow will proceed and hit the step to tear down the EC2, making it no longer reachable via ssh. |
| 51 | +For this reason you will probably have to run the Tmate session with `detached: false` and or add a timeout step to the ansible playbook, |
| 52 | +to make sure you still have something that the runner can SSH into. |
0 commit comments