Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal window close from task #782

Closed
Vlaaaaaaad opened this issue Sep 10, 2019 · 12 comments
Closed

Terminal window close from task #782

Vlaaaaaaad opened this issue Sep 10, 2019 · 12 comments
Labels
feature: terminal type: question reporter has a general question

Comments

@Vlaaaaaaad
Copy link

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.

@jankeromnes
Copy link
Contributor

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.

@jankeromnes jankeromnes added type: question reporter has a general question feature: terminal labels Sep 11, 2019
@jankeromnes
Copy link
Contributor

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

@jankeromnes
Copy link
Contributor

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"

@Vlaaaaaaad
Copy link
Author

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!

@Vlaaaaaaad
Copy link
Author

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"

@jankeromnes
Copy link
Contributor

jankeromnes commented Sep 11, 2019

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.

@Vlaaaaaaad
Copy link
Author

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?

@jankeromnes
Copy link
Contributor

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).

@Vlaaaaaaad
Copy link
Author

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!

@jankeromnes
Copy link
Contributor

jankeromnes commented Sep 26, 2019

@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?

@Vlaaaaaaad
Copy link
Author

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 😅

@jankeromnes
Copy link
Contributor

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. 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature: terminal type: question reporter has a general question
Projects
None yet
Development

No branches or pull requests

2 participants