Are env variables published in the prebuild workspace?

Hello,
in the prebuild workspaces documentation it says:

Note : prebuilds are executed as the user who installed the GitHub app. This means that if you want to use prebuilds on a private repository, the user who installed the GitHub app (e.g. you) need to give access to private repositories.

Does it means that everyone will have access to my SSH key if I do this?

tasks:
  - before: >
      mkdir ~/.ssh &&
      echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa

According to svenefftinge comment on this post I would say they don’t have access to it but I prefer to have a confirmation :slight_smile:

The before task is executed during prebuild before init as well as when starting a workspace before command.

However, at the moment only what is inside /workspace is backed-up, so whatever you write to your home directory will not survive a workspace restart and would therefore not be included in a prebuild.

So it would be ok at this time, but we are actively working on full backups and at that point the prebuild would include that data.

Would be interesting to learn what you are trying to achieve. Maybe there are better/other ways.

However, at the moment only what is inside /workspace is backed-up, so whatever you write to your home directory will not survive a workspace restart and would therefore not be included in a prebuild.

Oh, that’s interesting and could explain some bugs I had about my “build script” (missing dependencies) not working properly after a workspace restart.

Would be interesting to learn what you are trying to achieve. Maybe there are better/other ways.

My use case for needing my SSH key is because I am trying to consider Gitpod as my daily machine for working on OSS. So I am not only using it to code, review pull request, etc. but I also use it in order to publish my packages and release the documentation etc.

But, in my process, in order to release the documentation, I am using gh-pages which use git in order to clone/push the modifications. And, if I remember correctly it was complaining about not having the right to push the modifications and a solution I found for that was to use a “real ssh key” linked to my account.

Could it be that you used the ssh URL not the git one? Pushing changes to any GH repo should work fine as long as you have granted the corresponding scopes in https://gitpod.io/access-control/

If you still have that issue, I’d want to try reproducing it.

In general, I never use the ssh URL but I will double check.

If that’s not the case, I will provide a reproduction repo so you can take a closer look at it.

1 Like

Sorry for the delay, I finally had the time to explore my problem :slight_smile:

The fault was not due to gh-pages but something else.

In one of my repo build process, I am manually cloning a specific branch in order to update the documentation.

Example of command: git clone --single-branch git@github.com:MangelMaxime/Fulma.git

It is failing because it says that I don’t have the permissions. That’s why I needed to add my own key to .ssh/id_rsa.

I also noticed that if I used:

echo $SSH_PRIVATE_KEY > ~/.ssh/id_rsa

I have 2 problems.

First, the key is not secured enough:

Permissions 0644 for '/home/gitpod/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

Second, the key don’t have the right format:

Load key "/home/gitpod/.ssh/id_rsa": invalid format

The first one is easy enough to solve because I can make the process run chmod 0600 .ssh/id_rsa but for the second one, it’s harder because I think it’s due to Gitpod GUI which erase the newline probably.

This is not really blocking me right now, because I don’t publish a new version of the documentation every day and I can easily add my key if needed. Also, as you mentioned it’s probably not a good idea to automate my key addition so I am updating my build process to work seamlessly on Gitpod.

Hi Mangel,
Were you able to solve the second issue where the keys get saved in the wrong format?
Does the gitpod team have any recommendations or workarounds?
Thanks