A GitHub bot written in Rust for using GitLab CI in OSS projects.
- Listens for webhooks from GitHub
- Pushes branches to GitLab from external (forked) PRs
- Accepts commands by way of PR comments
- Possibly more coming soon 👻
Commands can be executed by commenting on a PR with your CI user's login.
@labhub retry
: retry a pipeline that has failed
GitLab has a great CI system, however it's not suitable for open source projects 😧 (at the time of writing) because it won't build external PRs by default. There are security concerns about the risk of exposing secrets in external builds, and GitLab errs on the side of caution by not building external PRs by default.
For more details on the issue, please take a look at this GitLab discussion.
If you're not concerned with leaking secrets, then LabHub may be for you! LabHub listens for webhooks from GitHub to notify for new pull requests. If the PR is from a forked repo, it will push a branch to GitLab (for the corresponding PR) to test the build.
Using LabHub? Open a PR to add your project here! 😀
LabHub is currently being used by the following projects:
LabHub requires Rust nightly. To compile using rustup
:
$ rustup toolchain install nightly
$ rustup default nightly
$ cargo build
Be sure to switch back to stable
with rustup default stable
if that's your preferred toolchain.
LabHub is configured using LabHub.toml
. For details, see src/config.rs. You can specify the path to LabHub.toml
by setting the LABHUB_TOML
environment variable.
You'll need to set up webhooks for any repo you wish to enable LabHub for. Currently, only GitHub webhooks are required. To get started, go to github.com/<org>/<repo>/settings/hooks
and add a new webhook.
Configure the webhook to send PR and push events.
- Set the payload URL path to
/github/events
, which is the path LabHub is expecting for GitHub events. - Create a secret (ex:
cat /dev/urandom | LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1
) and set the same value in the webhook config as in LabHub. - Make sure the payload type is
application/json
. - Here's how your webhook should look
You'll need a CI user with SSH keys for both GitHub and GitLab. Create an account on both sites (if you don't already have a CI user), and create an SSH key for LabHub:
$ ssh-keygen -f labhub-key.ecdsa -t ecdsa -b 521
Keep labhub-key.ecdsa
safe, and upload labhub-key.ecdsa.pub
to both GitHub and GitLab for the CI user.
Create personal access tokens for your CI user on both GitHub, and GitLab. Supply these tokens by setting the api_token
parameter in LabHub.toml
for both GitHub and GitLab.
- Go to https://github.com/settings/tokens
- Click "Generate new token"
- Give the token a name, and enable the
repo
scope, like this. - Save that token to your
LabHub.toml
- Go to https://gitlab.com/profile/personal_access_tokens
- Give the token a name, and enable the
api
scope, like this. - Save that token to your
LabHub.toml
There's a Helm chart included in this repo, which is the preferred method of deployment. To use you, you must first create the SSH key secrets with kubectl. Assuming your SSH private key is labhub-key.ecdsa
:
$ kubectl create secret generic labhub-ssh-keys --from-file=github=labhub-key.ecdsa --from-file=gitlab=labhub-key.ecdsa
You may use separate keys for GitHub and GitLab if you choose, respectively.
Once you have the secrets, install the helm chart from helm/labhub/:
$ cd helm/labhub/
$ cp values.yaml myvalues.yaml
### Edit myvalues.yaml to your liking ###
$ helm upgrade --install labhub . -f myvalues.yaml
- No periodic reconciling of GitLab branches with open PRs: if a webhook is missed for any reason, the GitLab pipeline may not correctly reflect the PR state