Terminal window close from task
Vlaaaaaaad opened this issue ยท 12 comments
Hi,
When having multiple tasks( be they init
, before
, or command
) a lot of terminals end up remaining open with... misleading titles. I'd love to be able to close the terminal on successful execution of the task.
I've tried both exit
which just closes the running command, but not the terminal window. Combinations of kill -9
and ps
led nowhere either.
Going further, for failing tasks I'd like the option to pretty print some helpful instructions: Hey, this failed cause X so please try running this command: ****, but that's more intense I think.
Hi @Vlaaaaaaad!
Normally, multiple tasks (init
, before
, command
) should run in a single Terminal. I'm guessing that you have multiple -
s in your .gitpod.yml
:
tasks:
- before: # ...
- init: # ...
- command: # ...
This will run all tasks in parallel in multiple Terminals. I think what you want instead is:
tasks:
- before: # ...
init: # ...
command: # ...
This will open a single Terminal (only one -
), and run before
, init
and command
sequentially.
Also, on a random note, you can give more relevant names to each Terminal, like so:
tasks:
- name: DB
init: ./install-db.sh
command: ./start-db.sh
- name: Server
init: ./install-server.sh
command: ./start-server.sh
Going further, for failing tasks I'd like the option to pretty print some helpful instructions: Hey, this failed cause X so please try running this command: ****, but that's more intense I think.
What you can do is use Bash's ||
operator for that, e.g.:
tasks:
- command: cat ohno.txt || printf "\nPlease try running 'touch ohno.txt' first.\n\n"
Yes, I had two tasks in .gitpod.yml
, like so:
image:
file: .gitpod/.gitpod.dockerfile
tasks:
- name: Install pre-commit hooks
command: pre-commit install --install-hooks && printf "\n \n \n Please close this window"
- name: SSH setup and Terraform init
command: >
.gitpod/ssh-terraform.sh
I wanted the user to see the SSH setup and Terraform init window when the workspace starts and the Install pre-commit hooks terminal window to close if it ran successfully.
Buuuut I think I can break SSH setup and Terraform init into two tasks and maaaybe combine them nicely. I will experiment now and report back -- I am planing to open-source this when it's ready either way.
Thank you so much!
I'd still like to have the option to close the Terminal window from a task so I will leave this open. Is that ok?
The following works great meanwhile:
image:
file: .gitpod/.gitpod.dockerfile
tasks:
- name: Prepare workspace
before: >
pre-commit install --install-hooks
&& printf "\n \n \n Please close this window"
init: > # This runs only on fresh workspace creation
.gitpod/ssh-keys-setup.sh
&& terraform init -backend=false -input=false
&& printf "\n \n \n Please close this window"
I'd still like to have the option to close the Terminal window from a task so I will leave this open. Is that ok?
Sure, although I'm not exactly sure what the use case would be, we can definitely leave this issue open until we figure out a way to programmatically close a Terminal. ๐
The following works great meanwhile:
Cool that you got it to work!
But just to be sure, are you certain that this is the intended behavior?
# Workspace creation steps (i.e. `before` && `init`)
pre-commit install --install-hooks
printf "\n \n \n Please close this window"
.gitpod/ssh-keys-setup.sh
terraform init -backend=false -input=false
printf "\n \n \n Please close this window"
# Workspace restart steps (i.e. just `before`)
pre-commit install --install-hooks
printf "\n \n \n Please close this window"
I find it strange that Please close this window
is printed twice in the main Terminal on workspace creation, and once every time you restart a workspace. Also if you close the main Terminal, you no longer have a visible Terminal to type any commands into.
Personally, I'd be tempted to simplify the tasks like so:
tasks:
- init: >
pre-commit install --install-hooks &&
.gitpod/ssh-keys-setup.sh &&
terraform init -backend=false -input=false
This would run all init steps in sequence (or show you exactly where it failed), and you'd only ever have one Terminal, which is simpler UX as having multiple Terminals opening and closing themselves.
Hm... I wanted to keep the SSH setup and Terraform init step in an init
task as to have it executed just once, when the workspace starts.
My logic is that:
- some people don't use private SSH modules so they don't need SSH keys setup. Spamming users with SSH keys setup prompts is not ideal
terraform init
is a rather intense step so running it on each workspace start is not desired. I think it's better to run it automatically at init and then just on demand. Like dependency installation --npm install
can take a while- pre-commit is helpful in 100% of the cases so I want to ensure it's always available for everybody
Does this make sense? Did I understand the order and usage of the tasks properly?
Thanks for the helpful clarifications! ๐
I wanted to keep the SSH setup and Terraform init step in an
init
task as to have it executed just once, when the workspace starts.
Actually, this will only be executed once, when the workspace is created. If you stop the workspace, and then click on "Start" again, only before
and command
will be run (not init
).
some people don't use private SSH modules so they don't need SSH keys setup. Spamming users with SSH keys setup prompts is not ideal
Aha, so indeed having this in a separate, less visible Terminal is a good idea.
However, if the SSH keys setup process is interactive (you're mentioning prompts), it should be done inside a command
and not an init
(because init
may be run non-interactively, to prepare workspaces before users arrive).
Now, command
will run every time you start a workspace (even when you stop and restart it), so you'll probably need some check that verifies if keys are already set up or not (and only prompt the users if the keys are not set up yet).
terraform init
is a rather intense step so running it on each workspace start is not desired. I think it's better to run it automatically at init and then just on demand. Like dependency installation --npm install
can take a while
That makes a ton of sense. Any long-running, non-interactive step that should be run once on workspace creation is a great candidate for init
.
With prebuilds, the init
step can already be run ahead-of-time by Gitpod, so that when you create a new workspace the result is already there and you don't have to wait.
pre-commit is helpful in 100% of the cases so I want to ensure it's always available for everybody
You're 100% correct here as well: any short environment setup step that should be run on every workspace start is a great fit for command
(or before
, if you need it to happen prior to any init
and/or command
steps).
Furthermore, if you want this to run on every shell session (e.g. re-run it when a user manually opens a new terminal), you may also consider adding that to /home/gitpod/.bashrc
).
After intense thought I decided not to do it completely different ๐
Workflows will always be different( SSH is needed for modules I work for a company for example, but not for modules in terraform-aws-modules). Having Gitpod start with a ton of terminals waiting for input just because it may be helpful is annoying UX.
I tried looking into setting up a custom command or something like that, but I did not find a way( other than an extension which is overkill).
So I decided to build a base image with all the helper scripts( which are still WIP) in ~/helpers
. Based on the desired workflows, the tasks can be configured whatever way the heart desires.
I have SSH setup( form env var or with krypt.co) and GPG setup( env var or krypt.co) which should be more than enough for now.
The pre-commit install is desired all the time so that's the only thing left:
image: vlaaaaaaad/gitpod-terraform:latest
tasks:
- name: Install pre-commit hooks
command: >
pre-commit install --install-hooks
&& printf "\n \n \n Please close this window
On that happy note I am closing this issue. Thank you for all your help!
@Vlaaaaaaad So cool that you managed to make it work! ๐
I tried looking into setting up a custom command or something like that, but I did not find a way( other than an extension which is overkill).
That's something we'd really like to have, but haven't been able to implement yet. See also #247, which proposes to support standard VS Code task definitions.
Meanwhile, building an image with helper scripts is a really cool and smart way to achieve that. ๐ฏ
I have SSH setup( form env var or with krypt.co) and GPG setup( env var or krypt.co) which should be more than enough for now.
Exciting! Does your env var setup work somewhat like this: #666 (comment) ?
Also, I didn't know krypt.co -- what would a SSH/GPG Gitpod setup with krypt.co look like?
Exciting! Does your env var setup work somewhat like this: #666 (comment) ?
Well, GPG is still to be implemented( I don't do any vanilla GPG cause UX), but the SSH helper does work that way( because I have colleagues who don't use krypt.co and want an env var)!
Also, I didn't know krypt.co -- what would a SSH/GPG Gitpod setup with krypt.co look like?
The workflow goes like this:
- Gitpod starts and a terminal has a QR code that needs to be scanned by the Krypt.co app
- the code is scanned, the pairing is done
- Krypt.co does some changes to the GPG and SSH config so it's redirecting
- for every usage of the private key, a notification is sent to the phone for authorization
Kind of like Yubikeys, but with a phone app. I like it because I always have my phone with me ๐
That's a super cool SSH helper! Thanks a lot for sharing it. ๐
Also, Krypt.co does sound like a very useful utility. Maybe we could somehow integrate it into Gitpod itself to make SSH/GPG UX more convenient. E.g. if Krypt.co ever ships a VS Code extension that does the QR code setup, we could install it by default in Gitpod. โจ
In any case, the helper scripts you wrote look like they'll work really well -- good luck with your project! Please feel free to reach out if you'd like help with anything else. ๐