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.
Related
My CI/CD is: git > cicleci > heroku
I'm using circleci's suggested configuration (attached below)
I have the proper environment variable in circleci.
The first part is working well, however, when I deploy to heroku I can see warnings from devs dependencies like:
./src/hooks/myHook.js
Line 11: React Hook useEffect has a missing dependency: 'x'. Either include it or remove the dependency array react-hooks/exhaustive-deps
which makes me think that React dev is running.
Can anyone help me?
version: 2
jobs:
build:
...
deploy:
docker:
- image: buildpack-deps:trusty
steps:
- checkout
- run:
name: Deploy Master to Heroku
command: |
git push https://heroku:$HEROKU_API_KEY#git.heroku.com/$HEROKU_APP_NAME.git master
workflows:
version: 2
build-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only: master
I'm not sure if you are already but I highly recommend using this Heroku buildpack rather than the standard Heroku Node buildpack: https://github.com/mars/create-react-app-buildpack. This buildpack starts in production by default.
In Heroku go to settings > Buildpacks and click on the Add buildpack, then enter the following url: https://github.com/mars/create-react-app-buildpack.git and save.
However if there is a hook error as above I would fix that issue by adding it into the dependency array in the hook.
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
I'm trying to do the following with Bitbucket Pipelines when i push to my test brand:
- git fetch
- git checkout master
- git pull origin test
- git push origin master
But i get the following message on git fetch: Permission denied (publickey). I was following this tutorial https://confluence.atlassian.com/bitbucket/use-ssh-keys-in-bitbucket-pipelines-847452940.html so i already added an ssh key, but cannot understand what are the next steps that i need for the execution to have permissions to connect to the repository.
If “from same repository” really means that you want to access the repository in which the pipeline runs, the answer is: you don’t need that. When the pipeline runs, it starts the Docker image you defined in your YAML configuration and automatically checks out the commit you pushed. This means that at the moment when when your command (git fetch) is executed, the sources are already waiting for you in path /project.
BitBucket Pipelines automatically checks out the repository upon running. However, if you want to make changes to the repository (e.g. git tag or git push) you will need to add the SSH keys according to the post you have already found (https://confluence.atlassian.com/bitbucket/use-ssh-keys-in-bitbucket-pipelines-847452940.html). That works for our environment.
Can you post the full bitbucket-pipelines.yml file?
I want to deploy my app to heroku and here is my pipeline file
image: node:6
clone:
depth: full
pipelines:
default:
- step:
script:
- npm install
- npm test
- git push https://heroku:$HEROKU_API_KEY#git.heroku.com/$HEROKU_APP_NAME.git HEAD:master
I set the HerokuAppkey and herokuappname in enviroment variables, but i've got error
+ git push https://heroku:$HEROKU_API_KEY#git.heroku.com/$HEROKU_APP_NAME.git HEAD:master
remote: ! WARNING:
remote: ! Do not authenticate with username and password using git.
remote: ! Run `heroku login` to update your credentials, then retry the git command.
remote: ! See documentation for details: https://devcenter.heroku.com/articles/git#http-git-authentication
fatal: Authentication failed for 'https://heroku:#git.heroku.com/humolite.git/'
Go to Heroku Account Setting then regenerate api key and replace to $HEROKU_API_KEY.
It appears you've set your account's password to $HEROKU_API_KEY. You need to set a valid token instead.
You can use teh heroku authorizations:create command to create a new token locally. Then, configure your CI to have the right value and your deployment should be working.
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.