-
Notifications
You must be signed in to change notification settings - Fork 798
Description
Problem
External contributors will NOT have green builds due to the fact that non-write-access contributors will not have access to GIT_API_KEY and thus the gh-assets-clone.sh
script will fail every time during the build.
Details
I've run into this issue when building my pull request (recently): #202
The only error in my build originated from the gh-assets-clone.sh
script.
The script is short. Here is the code:
#!/bin/bash
# Script to setup the assets clone of the repository using GIT_ASSETS_BRANCH and
# GIT_API_KEY.
# the following check if GIT_ASSETS_BRANCH and GIT_API_KEY are not empty before
# proceeding to setup_git()
[ ! -z "$GIT_ASSETS_BRANCH" ] || exit 1
[ ! -z "$GIT_API_KEY" ] || exit 1
setup_git() {
git config --global user.email "travis@travis-ci.org" || exit 1
git config --global user.name "Travis CI" || exit 1
}
# Constants
ASSETS_DIR=".assets-branch"
# Clone the assets branch with the correct credentials
git clone --single-branch -b "$GIT_ASSETS_BRANCH" \
"https://${GIT_API_KEY}@github.com/${TRAVIS_REPO_SLUG}.git" "$ASSETS_DIR" || exit 1
The build is exiting here: [ ! -z "$GIT_API_KEY" ] || exit 1
right after passing the initial check with the assets branch. I have checked this by adding echo statements after each check to see if the checks pass by inspecting the build log.
So I wondered, why is the check passing $GIT_ASSETS_BRANCH but not $GIT_API_KEY?
When checking the travis build config, I found the following global env variables:
"global_env": "DOCKER_USER=wrouesnel DOCKER_PASS=[secure] GIT_ASSETS_BRANCH=assets GIT_API_KEY=[secure]",
Notice that on the far right, GIT_API_KEY is not shown publicly while GIT_ASSETS_BRANCH is. The placeholder that Travis CI shows us for GIT_API_KEY is "[secure]".
That's OK. I'm NOT advocating for showing us the GIT_API_KEY in plain text!
The issue, however, is that for external contributors (such as myself) who trigger a build, the GIT_API_KEY is returned by Travis as an empty string.
Consequently, this results in the gh-assets-clone.sh
script to fail here: [ ! -z "$GIT_API_KEY" ] || exit 1
So why is it the case that GIT_API_KEY is returned as an empty string? Please read the following carefully:
According to https://blog.algolia.com/travis-encrypted-variables-external-contributions/
"The way encrypted environment variables works is that you use the travis gem to add encrypted variables to your .travis.yml. Those keys are then automatically decoded by Travis at build time, but only for builds triggered by contributors with write access to the repository — not for forks, meaning not for external contributors’ PRs."
This could potentially lead to a bad contributor experience.
Proposed Solutions
- Follow the solution proposed from this blog post: https://blog.algolia.com/travis-encrypted-variables-external-contributions/
- If the Assets branch is not essential for external contributors, consider removing the
gh-clone-assets.sh
script from the build log. - Modify the script so that if the build is triggered from an external contributor who doesn't have write access to the repo, then skip running that gh-clone-assets.sh script (unless it is essential for the build)
I think that if I modify the gh-assets-clone.sh
script to skip all checks, I can get a green build. I think this is not ideal, so if I do get a green build, do not merge right away. Let's discuss what steps to take next.