I have an issue with gitlab, gitlab-ci and fastlane. In fastlane, I am using :
def increment_build_and_commit
incrementBuildNumber()
commit_version_bump(message: 'build number bump [skip ci]')
push_to_git_remote(
remote: 'origin_rw',
remote_branch: ENV['CI_COMMIT_BRANCH']
)
end
So I want to increase build number and commit. So it does the job with:
incrementBuildNumber(),
commit_version_bump(message: 'build number bump [skip ci]')
But when running, it fails at push_to_git_remote
[!] Exit status of command 'git push origin_rw HEAD:HEAD --tags
--set-upstream' was 1 instead of 0. error: The destination you provided is not a full refname (i.e., starting with "refs/"). We
tried to guess what you meant by:
Looking for a ref that matches 'HEAD' on the remote side.
Checking if the being pushed ('HEAD') is a ref in "refs/{heads,tags}/". If so we add a corresponding
refs/{heads,tags}/ prefix on the remote side. Neither worked, so we
gave up. You must fully qualify the ref. hint: The part of the
refspec is a commit object. hint: Did you mean to create a new branch
by pushing to hint: 'HEAD:refs/heads/HEAD'? error: failed to push
some refs to '**********.git'
Some of you have any clues what to do and how to solve this problem? As I am going to be a google machine on that, but unfortunetly can't find the solution.
Thanks in advance!!
This happens because gitlab-ci checkouts git commit instead of git branch and you enter detached HEAD state.
There are few ways to get around this:
1) Use CI provided value. For GitLab I would recommend using CI_PIPELINE_IID. Downside is that you cannot control it and if you migrate your project to other repository it will start from 1 again.
2) Checkout git branch before making commit. Downside is that if other developer pushes to the same branch, your pipeline will continue with wrong source code.
3) Commit version number bump manually.
Related
When I push an empty branch to my GitHub repo (perhaps by creating a branch through the GitHub web UI), CircleCI sees it and runs all the tests for the commit at the tip of that branch.
This makes sense, but I've discovered an unfortunate side effect: the CircleCI jobs for the branch clobber the GitHub statuses for master with inaccurate information.
Here's the sequence of events:
I push commit A to master. This runs my whole CircleCI workflow and posts information on test success / failure for A to GitHub using the GitHub Status API.
I create a new branch, mybranch, using the GitHub UI. Its tip is also at commit A.
CircleCI runs all the tests for mybranch. These are also on commit A, so CircleCI re-posts statuses to the GitHub status API for commit A.
This might be OK, except that I have an optimization: I early-out of tests that shouldn't be affected by a PR branch. So if the branch contains no TypeScript files in its diff from master, I won't run the TypeScript tests. Unfortunately, this means that step 3 overrides the GitHub status for the full run on commit A with one that early outs (since there are no commits, there's no diff).
Here's what the "skip" logic looks like:
skip-job-if-no-ts:
description: Skips the rest of the job if files under ts/ have not been modified
steps:
- when:
condition:
not:
or:
# Always run all tests if this is a commit to master branch
- equal: [master, << pipeline.git.branch >>]
steps:
- run:
name: skip-job-if-no-ts
command: |
# Skip the rest of the job if ts/ wasn't modified
TS_CHANGED=$(git diff $(git merge-base HEAD origin/master) --name-only ts/)
if [ ! -n "$TS_CHANGED" ]; then
circleci-agent step halt
fi
How can I prevent CircleCI from running my job on an empty branch? I found an old discussion of this issue on the CircleCI forums, but it was closed with no comments.
I am trying to set up Chromatic in Travis.
I saw Chromatic document recommends using this script in Travis
if [[ $TRAVIS_EVENT_TYPE != 'pull_request' || $TRAVIS_PULL_REQUEST_SLUG != $TRAVIS_REPO_SLUG ]];
then
npm run chromatic
fi
with explanation
Travis offers two type of builds for commits on pull requests: so
called pr and push builds. It only makes sense to run Chromatic once
per PR, so we suggest disabling Chromatic on pr builds for internal
PRs (i.e. PRs that aren’t from forks). You should make sure that you
have push builds turned on, and add the following code: [[THE CODE ABOVE]]
For external PRs (PRs from forks of your repo), the above code will
ensure Chromatic does run on the pr build, because Travis does not
trigger push builds in such cases.
Note: We recommend running Chromatic on push builds as pr builds can't
always run and fall out of the normal git ancestry. For instance, if
you change the base branch of a PR, you may find that you need to
re-approve changes as some history may be lost.
Chromatic does work with Travis pr builds however!
Then I read the Travis document about TRAVIS_PULL_REQUEST_SLUG and TRAVIS_REPO_SLUG.
TRAVIS_PULL_REQUEST_SLUG:
if the current job is a pull request, the slug (in the form
owner_name/repo_name) of the repository from which the PR originated.
if the current job is a push build, this variable is empty ("").
TRAVIS_REPO_SLUG:
The slug (in form: owner_name/repo_name) of the repository currently being built.
So my understanding is when $TRAVIS_PULL_REQUEST_SLUG != $TRAVIS_REPO_SLUG, it is a push build, then why it still needs $TRAVIS_EVENT_TYPE != 'pull_request'?
Is there any difference between them?
Gert from Chroma here.
We recommend to run chromatic only when a build does not originate from a pull request (i.e. a push build), OR when it is a pull request build originating from a fork, in which case the PR slug differs from the repo slug.
Based on the quoted Travis docs, in case of a push build, TRAVIS_PULL_REQUEST_SLUG is empty, in case of a PR build from a fork, it will reference the fork's repo owner. In either case it will be different from TRAVIS_REPO_SLUG. So you're correct that the left-hand side of this condition is superfluous. Feel free to omit it.
I have configured jenkins with gerrit trigger plugin to validate every commit we push to gerrit.
I am expecting this trigger to include my latest change with original repo and make a build.
But, it is cloning only repo project and compiling without my change.
Below is my configuration settings for gerrit trigger in jenkins.
Refspec: $GERRIT_REFSPEC
Branches to build: $GERRIT_BRANCH
Build trigger: Gerrit event
Trigger on: patch set created
Gerrit project: added project and branch
Below is the build output message
Triggered by Gerrit: http://ci-test1/22
Building on master in workspace /var/lib/jenkins/jobs/Build_Adserver_4.7/workspace
Checkout:workspace / /var/lib/jenkins/jobs/Build_Adserver_4.7/workspace - hudson.remoting.LocalChannel#733aee56
Using strategy: Default
Last Built Revision: Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
Fetching changes from 1 remote Git repository
Fetching upstream changes from abc
Commencing build of Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
Checking out Revision 701a75ef38aa191ac1b806c48e6b3451671888f6 (ads/4.7)
[workspace] $ /bin/sh -xe /tmp/hudson1375188638196718521.sh
+ echo 'Started Build'
Started Build
+ echo ..................
..................
+ echo 'Build Finished'
Build Finished
Finished: SUCCESS
Here 701a75ef38aa191ac1b806c48e6b3451671888f6 is HEAD of repo branch and 8cbda558adcad4fb7eb714e0b3fb98a6fbf5811c is the SHA-id of my latest change trigged the build.
I verified from jenkins workspace also, it doesn't include my change.
sorry if I am missing any information to mention. Please let me know
please help me if I am missing anything here.
Using Jenkins 1.532.2 Git Client Plugin 1.6.2 Git Plugin 2.0.1 Git Trigger 2.11.0
Here are the steps for configuring the Gerrit Trigger (from memory, hopefully all works fine):
Install the plugin(s) "Gerrit Trigger", "Git Plugin" and "Git Client Plugin"
In the main jenkins config (HOME->Manage Jenkins), click on Gerrit Trigger.
Create the server and configure it. Use "Test Connection" to be sure it works.
At the end, under "Control" press "start" (No idea what that does or if it's actually needed, but I did that).
Go to your project's config (MYPROJECT->Configure)
Check "Gerrit event" under "Build Triggers"
In the newly added menu, select your server, your triggers, etc.
For Gerrit Project I used "Plain" with "MYPROJECT" as pattern
For Branch, I used "Path" and "**" as pattern (builds all branches)
Under "Source Code Management" (up from triggers in my UI), click on "Git"
Set the Repository URL, here $USER matches for me, but otherwise write the correct user $GERRIT_SCHEME://$USER#$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
Specify a branch: $GERRIT_BRANCH
Under "Repositories" on the right, click Advanced, for "Refspec" enter $GERRIT_REFSPEC
Click Add right below, and select "Strategy for choosing what to build"
Select "Gerrit Trigger"
Not very intuitive but it should work. I suggest making sure the correct SHA1 Ids are being built.
If run into Error stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC
You have to change the Choosing Strategy to Gerrit Trigger
Go to the configuration page of your job and then click on the 2nd Advanced button under the git section. Almost at the bottom there is a Choosing Strategy that you will need to change to Gerrit Trigger
This will cause Git to fetch the correct version for your build
Fixing small issues in Lewis answer, change the values to the following to ensure the latest SHA1 is built.
branch: $GERRIT_REFSPEC
REFSPEC: $GERRIT_REFSPEC:$GERRIT_REFSPEC
I am using Jenkins 2.15 and faced the Issue and got resolved with following settings.
In Git Advances add Refspec : $GERRIT_REFSPEC
Branches to build : $GERRIT_BRANCH.
In Addititional behaviors section select Strategy for choosing what to build and select gerrit Trigger.
Using Travis-CI, is it possible to trigger a rebuild without pushing a new commit to GitHub?
Use case: A build fails due to an externality. The source is actually correct. It would build OK and pass if simply re-run.
For instance, an apt-get fails due to a package server being down, but the server is back up again. However the build status is "stuck" at "failed" until a new commit is pushed.
Is there some way to nudge Travis-CI to do another build, other than pushing a "dummy" commit?
If you have write access to the repo: On the build's detail screen, there is a button ↻ Restart Build. Also under "More Options" there is a trigger build menu item.
Note: Browser extensions like Ghostery may prevent the restart button from being displayed. Try disabling the extension or white-listing Travis CI.
Note2: If .travis.yml configuration has changed in the upstream, clicking rebuild button will run travis with old configuration. To apply upstream changes for travis configuration one has to add commit to PR or to close / reopen it.
If you've sent a pull request: You can close the PR then open it again. This will trigger a new build.
Restart Build:
Trigger Build:
If you open the Settings tab for the repository on GitHub, click on Integrations & services, find Travis CI and click Edit, you should see a Test Service button. This will trigger a build.
I know you said without pushing a commit, but something that is handy, if you are working on a branch other than master, is to commit an empty commit.
git commit --allow-empty -m "Trigger"
You can rebase in the end and remove squash/remove the empty commits and works across all git hooks :)
I have found another way of forcing re-run CI builds and other triggers:
Run git commit --amend --no-edit without any changes. This will recreate the last commit in the current branch.
git push --force-with-lease origin pr-branch.
If you have new project on GitHub which has .travis.yml, but was never tested, you can run tests without commit this way:
enable testing in Travis CI setings
open project page on GitHub
open settings -> webhooks and services
find Travis CI in services and press edit button
press "Test service"
You can do this using the Travis CLI. As described in the documentation, first install the CLI tool, then:
travis login --org --auto
travis token
You can keep this token in an environment variable TRAVIS_TOKEN, as long as the file you keep it in is not version-controlled somewhere public.
I use this function to submit triggers:
function travis_trigger() {
local org=$1 && shift
local repo=$1 && shift
local branch=${1:-master} && shift
body="{
\"request\": {
\"branch\": \"${branch}\"
}
}"
curl -s -X POST \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "Travis-API-Version: 3" \
-H "Authorization: token $TRAVIS_TOKEN" \
-d "$body" \
"https://api.travis-ci.org/repo/${org}%2F${repo}/requests"
}
Travis now offers a way to trigger a "custom" build from their web UI. Look for the "More Options" menu button on the right side near the top of your project's page.
You'll then be presented with a dialog box in which you can choose the branch and customize the configuration:
At the time I'm writing this it is in beta, and appears to be slightly buggy (but I expect they'll get the problems ironed out soon).
If you install the Travis CI Client you can use travis restart <job#> to manually re-run a build from the console. You can find the last job# for a branch using travis show <branch>
travis show master
travis restart 48 #use Job number without .1
travis logs master
UPDATE: Sadly it looks like this doesn't start a new build using the latest commit, but instead just restarts a previous build using the previous state of the repo.
If the build never occurred (perhaps you didn't get the Pull-Request build switch set to on in time), you can mark the Pull Request on Github as closed then mark it as opened and a new build will be triggered.
I should mention here that we now have a means of triggering a new build on the web. See https://blog.travis-ci.com/2017-08-24-trigger-custom-build for details.
TL;DR
Click on "More options", and choose "Trigger build".
I just triggered the tests on a pull request to be re-run by clicking 'update branch' here:
Here's what worked for me to trigger a rebuild on a PR that Dependabot had opened, but failed due to errors in .travis.yml:
Close the PR
Wait for Dependabot to comment ("OK, I won't notify you again about this release, but will get in touch when a new version is available."). It will remove its branch.
Restore the branch Dependabot removed (something like dependabot/cargo/tempfile-3.0.4).
Open the PR again
Please make sure to Log In to Travis first. The rebuild button doesn't appear until you're logged in. I know this is obvious, but someone just tripped on it as well ;-)
sometimes it happens that server do made some mistakes.
try log out/sign in and everything might be right then.
(Yes it happened this afternoon to me.)
Simlpy close and re-open the PR if you do not have the write access.
I know there is a http deploy hook I can use but unfortunately it does not submit the branch name, here is what it does submit:
{"head"=>"7021419", "app"=>"appname", "git_log"=>"commit message", "action"=>"home", "url"=>"site url", "prev_head"=>"1d844b0", "controller"=>"account_sessions", "user"=>"heroku#user.com", "head_long"=>"7031429230228988d8f3312fa9e74d77b6c1bc14"}
I tried using the head or head_long to figure out the branch name with:
git branch --contains SHA
Which worked, but it is not 100% accurate as the same SHA could be in multiple branches. Same can be said about:
git reflog show --all | grep 7021419
I am pretty sure it is impossible to get the current branch name from within the deployed app as the branch deployed to Heroku is always the "master" branch. I was hoping I can send the deploy callback hook to another server and store the deployment record somewhere.
1. Detecting only
If it's just about heads, use
git rev-list --no-walk --glob=refs/heads
with a bit of --format and grep logic tacked on
2. Tracking locally
The simplest way would be using a tag.
Push the tag like a normal branch:
git push herokuremote tagname:publicbranchname
Unfortunately, that would just push the tag, not a branch... ; read on for alternative
(note I don't know/use heroku, so I don't know the naming conventions, sorry)
3. Symbolic branch reference
If you don't mind using a bit of plumbing, you can name a local ref as the one deployed. You can have a symbolic ref for the purpose:
git update-ref -m "deployed release candidate" --no-deref refs/heads/deployed master
If the same SHA is in multiple branches, they are effectively the same branch (at least at that point in time). If you're sure that SHA is the last commit of a branch, you can find it in .git/refs/heads/* where * is a list of files whose names correspond to branch names and contents are the SHAs.
It seems like you might be able to solve this recording problem by not using their API. Wrapping your deploy script (or Heroku's deploy binary, or a post-push hook) should give you the flexibility you need to notify a different service for record keeping.