I'm setting up my Travis Ci integration with my GitHub pages repo and I'm getting this error when committing to my dev branch, which on completion should automatically commit to my master branch.
My Error:
gh-token is invalid. Details: GET https://api.github.com/user: 401 - Bad credentials // See: https://developer.github.com/v3
My git flow is as follows:
I use dev as an intermediary branch. The application is using vue.js and required a production build, which the production build is what should be pushed to master.
push local branch to remote branch
create a pull request on remote feature branch to the dev branch
merge feature branch with dev branch (this is when Travis CI should push to master)
Here is my current .travis.yml
if: branch = dev
language: node_js
node_js:
- "lts/*"
cache:
directories:
- "node_modules"
script:
- set -e
- npm run build
deploy:
provider: pages
skip_cleanup: true
github_token: GITHUB_TOKEN
keep_history: true
local_dir: build
target_branch: master
on:
branch: dev
I've confirmed my GitHub access token and tried increasing permissions. The token I'm currently using only has public repo access, which is based on the Travis CI docs
Might be an easy fix.
Have you tried access GITHUB_TOKEN like an environment variable?
github_token: $GITHUB_TOKEN
Related
I have one server on my Forge account with two sites. One is a production site while the other is a staging website. For example:
domain.com
test.domain.com
Both rely on the same Github repository, the staging site should be deployed when a commit is pushed to the develop branch while production should be deployed when anything is pushed to the main branch.
What did I do:
I added the deployment hook of both sites into the secrets of the Github repository:
FORGE_DEPLOYMENT_HOOK_PRODUCTION
FORGE_DEPLOYMENT_HOOK_STAGING
Then I created a Github action for both sites which starts on push to either branch and makes a curl request to the deployment hook:
name: Deploy production
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy Site
run: curl ${{ secrets.FORGE_DEPLOYMENT_HOOK_PRODUCTION }}
I added the site’s deploy key of the production site (domain.com) to the repository deploy keys. When I try to add the staging key (test.domain.com) I get the error: Key is already in use. If I check the key it is actually a different key except for the first x amount of characters. Because I can’t add the key the action only works for the production site and not the staging site. I get this error when deploying staging:
ERROR: Repository not found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
So my question is: how can I add the second deploy key? And if this is not possible, what would be the best way to setup my Github actions to achieve the same goal? I thought this to be the easiest way.
I'm having the following circleCi config :
version: 2
jobs:
build:
machine: true
branches:
ignore: gh-pages
steps:
- run: echo "Skipping tests on gh-pages branch"
deployment:
machine:
node:
version: 6.11.2
npm:
version: 3.10.10
branch: ci
steps:
- run: git config --global user.email "<GITHUB_USERNAME>#users.noreply.github.com"
- run: git config --global user.name "<YOUR_NAME>"
- run: echo "machine github.com login <GITHUB_USERNAME> password $GITHUB_TOKEN" > ~/.netrc
- run: cd website && npm install && GIT_USER=<GIT_USER> npm run publish-gh-pages
that aims to deploy a https://docusaurus.io/ site on my github page.
Actually, when the CI runs on the ci branch, it should run the deployment job.
Actually, the deployment job is never triggered and I don't understand why.
I'm well building my ci branch
Here's my circleci build :
This is not running correctly because the config you are using is completely incorrect. There's aspects of CircleCI 2.0 configuration and aspects of CircleCI 1.0 configuration.
I'd recommend choosing one platform (CircleCI 2.0) and then going through the configuration reference for that version. Here's the configuration reference for CircleCI 2.0: https://circleci.com/docs/2.0/configuration-reference/
Feel free to do that, come back and update your question, or post a question at https://discuss.circleci.com.
Respectfully,
Ricardo N Feliciano
Developer Evangelist, CircleCI
With my colleagues, we work on a C++ library that becomes more and more important each day. We already built continuous integration utilities through the gitlab-ci.yml file that let us:
Build & Test in Debug mode
Build & Test in Release mode
Perform safety checks like memory leaks using Valgrind and checking if there is any clear symbol in our library we don't want inside it
Generate documentation
All kind of stuff that made us choose GitLab !
We would like to profile our whole library and push the benchmarks in a separate project. We have already done something like for out documentation using the SSH key method but we would like to avoid this this time.
We tried a script like this:
test_ci_push:
tags:
- linux
- shell
- light
stage: profiling
allow_failure: false
only:
- new-benchmark-stage
script:
- git clone http://gitlab-ci-token:${CI_JOB_TOKEN}#gitlab.mycompany.home/developers/benchmarks.git &> /dev/null
- cd benchmarks
- touch test.dat
- echo "This is a test" > test.dat
- git config --global user.name "${GITLAB_USER_NAME}"
- git config --global user.email "${GITLAB_USER_EMAIL}"
- git add --all
- git commit -m "GitLab Runner Push"
- git push http://gitlab-ci-token:${CI_JOB_TOKEN}#gitlab.mycompany.home/developers/benchmarks.git HEAD:master
- cd ..
We also tried a basic git push origin master to push our updated files but each time we got the same answer:
remote: You are not allowed to upload code for this project.
fatal: unable to access 'http://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx#gitlab.mycompany.home/developers/benchmarks.git/': The requested URL returned error: 403
Both projects are under the same site and I have the rights to push in both. Where am I doing anything wrong here ?
The gitlab ci token is more like the deploy key in github.com, so it only has read access to the repository. To actually push you will need to generate a personal access token and use that instead.
First you need to generate the token as shown here in the gitlab documentation. Make sure you check both the read user and api scopes. Also this only works in GitLab 8.15 and above. If you are using an older version and do not wish to upgrade there's an alternative method I could show you but it is more complex and less secure.
In the end your gitlab-ci.yml should look something like this:
test_ci_push:
tags:
- linux
- shell
- light
stage: profiling
allow_failure: false
only:
- new-benchmark-stage
script:
- git clone http://gitlab-ci-token:${CI_JOB_TOKEN}#gitlab.mycompany.home/developers/benchmarks.git &> /dev/null
- cd benchmarks
- echo "This is a test" > test.dat
- git config --global user.name "${GITLAB_USER_NAME}"
- git config --global user.email "${GITLAB_USER_EMAIL}"
- git add --all
- git commit -m "GitLab Runner Push"
- git push http://${YOUR_USERNAME}:${PERSONAL_ACCESS_TOKEN}#gitlab.mycompany.home/developers/benchmarks.git HEAD:master
- cd ..
While the previous answers are more or less fine, there are some important gotya's.
before_script:
- git config --global user.name "${GITLAB_USER_NAME}"
- git config --global user.email "${GITLAB_USER_EMAIL}"
script:
- <do things>
- git push "https://${GITLAB_USER_LOGIN}:${CI_GIT_TOKEN}#${CI_REPOSITORY_URL#*#}" "HEAD:${CI_COMMIT_TAG}"
For one, we only need to set the username/email to please git.
Secondly having it in the before script, is not super crucial, but allows for easier reuse when doing 'extend'.
Finally, pushing https is 'fine' but since we're not using a stored ssh key, we should avoid anything that can reveal the token. For one, while gitlab won't print the token in this command, git will happily inform us that the new upstream is set to https://username:thetokeninplaintexthere#url
So there's your token in plain text, so don't use -u to set an upstream.
Also, it's not needed, we are only doing a single push.
Further more, when determining the URL, I found that using the exist CI_REPOSITORY_URL to be the most reliable solution (when moving repo's for example or whatnot). So we just replace the username/token in the URL string.
You could also provide user and password (user with write access) as secret variables and use them.
Example:
before_script:
- git remote set-url origin https://$GIT_CI_USER:$GIT_CI_PASS#$CI_SERVER_HOST/$CI_PROJECT_PATH.git
- git config --global user.email 'myuser#mydomain.com'
- git config --global user.name 'MyUser'
You have to define GIT_CI_USER and GIT_CI_PASS as secret variables (you could always create dedicated user for this purpose).
With this configuration you could normally work with git. I'm using this approach to push the tags after the release (with Axion Release Gradle Pluing - http://axion-release-plugin.readthedocs.io/en/latest/index.html)
Example release job:
release:
stage: release
script:
- git branch
- gradle release -Prelease.disableChecks -Prelease.pushTagsOnly
- git push --tags
only:
- master
I'm using the following GitLab job:
repo_pull_sync:
image: danger89/repo_mirror_pull:latest
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
- if: $REMOTE_URL
- if: $REMOTE_BRANCH
- if: $ACCESS_TOKEN
before_script:
- git config --global user.name "${GITLAB_USER_NAME}"
- git config --global user.email "${GITLAB_USER_EMAIL}"
script:
- git checkout $CI_DEFAULT_BRANCH
- git pull
- git remote remove upstream || true
- git remote add upstream $REMOTE_URL
- git fetch upstream
- git merge upstream/$REMOTE_BRANCH
- git push "https://${GITLAB_USER_LOGIN}:${ACCESS_TOKEN}#${CI_REPOSITORY_URL#*#}" "HEAD:${CI_DEFAULT_BRANCH}"
I'm using my own danger89/repo_mirror_pull docker image based on alpine, check this GitHub repository for more info.
This GitLab job pull upstream changes from the predefined remote repository + branch (see variables below), and merge them locally in CI/CD and pushes them in GitLab again.
Basically I created a repository pull mirror (which is officially not available for free on GitLab CE, only a push mirror is supported in GitLab).
Create in GitLab a Project Access Token first in GitLab. Via: Settings->Access Tokens. Check 'api' as the scope.
Create a new schedule, via: CI/CD->Schedules->New schedule. With the following 3 variables:
REMOTE_URL (example: https://github.com/project/repo.git)
REMOTE_BRANCH (example: master)
ACCESS_TOKEN: (see Access Token in the first step! Example: gplat-234hcand9q289rba89dghqa892agbd89arg2854, )
Save pipeline schedule
Again, see also: https://github.com/danger89/repo_pull_sync_docker_image
Regarding the question, see the git push command above, which allows you to push changes back into GitLab using GitLab (project) access token.
I am trying to use the Bitbucket Pipelines feature to deploy a node.js project to Heroku. The script(taken from documentation) is:
image: node:6
clone:
depth: full
pipelines:
default:
- step:
script:
- npm install
- git push https://heroku:$HEROKU_API_KEY#git.heroku.com/$HEROKU_APP_NAME.git master
I have set up the enviorment variables for the API key and project name however I am getting the following error:
+ git push https://heroku:$HEROKU_API_KEY#git.heroku.com/$HEROKU_APP_NAME.git master
fatal: remote part of refspec is not a valid name in .git
What am I doing wrong here?
As it turned out when I copied the app_name environment variable I copied it with a trailing space which was the error.
This will work, but in my experience so far the token expires every 8 hours so you'll have to find a different solution.
I am trying to get Travis-CI to automatically deploy a successful tagged build to Heroku. Below is my .travis.yml setup:
deploy:
provider: heroku
strategy: git
run:
- "rake db:migrate"
- restart
on:
tags: true
Upon tagging the repository:
git tag -a 1.0.0 -m "release 1.0.0"
and pushing to the remote repository, Travis-CI kicks off the build but exits immediately after the following:
$ git fetch --tags
Done. Your build exited with 0.
Travis-CI does not deploy the application to Heroku. Am I missing a piece?
There is currently a glitch with on: tags: true that the condition is never met and the code will never trigger a deploy. The github issue is here. The issue should be resolved soon, and in the meantime you can use a branch like releases to update your heroku app with on:branch.
Update:
To fix on:tags, you can do this, as refrenced in the above github issue.
on:
tags: true
all_branches: true