I haven't used Travis-CI but I can see that some GitHub commits have a green mark which shows that Travis build has succeeded and some have a red mark which shows that Travis builds failed. But I am wondering why do a few commits don't have any status?
I am looking at the commits of apache commons-math.
Presumably there were multiple commits locally, which was only pushed after commit 583d9ec. Given that the status of an old commit is irrelevant, Travis CI ignores those and only builds the most recent (source). If any issues did arise, a build could have still been manually triggered, revealing which commit broke something.
Related
Been using production/integration branches to manage code promo to production. Our integration branch is a stable integration environment that all feature branches are made from, and merges are reviewed by PR, and deployed via CI when approved and squashed+merged. Once integration is stable and we've tested it, we do another PR from integration to production. When this is approved and squashed+merged, CI takes over and deploys to the production env.
git checkout integration
git checkout -b feature
# do work
git add/commit etc
# create PR, squash+merge on github UI when reviewed
# CI sees new commit to integration, deploys to int env
My issue is with what these integration -> production PRs looks like when they are reviewed - even though (at times) I've done the following to get any commits already in production into integration:
git checkout integration
git pull
git pull origin production
git push
# create PR for integration merge into production
When I go look at the PR page on Github, the list of commits shows history going back to commits that are already represented in production. The "Files changed" list is very small, while the commit history goes back many PRs ago. I thought git pull origin production would remove this history and then only show the new commits coming from integration to production?
Am I missing some obvious way to maintain merge commits but also clean up the history when integration is merged into production? Could inconsistent merging/rebasing strategies cause this?
Some screenshots to show what is confusing - a PR that has a single file changed from a single commit, but the commit history goes back much further:
The single file change was the last commit in the list—why does the PR show commits that have already been merged previously? I thought Squashing and Merging (both into integration from feature branches and into master from integration would remove this commit history and make merges into master clean?
The green arrow represents the 1 file changed in this PR, and I thought the commit history (after a merge of production back into integration to clean the history, if any) would only have that one commit.
Is this a github display bug or am I missing some principle of how git maintains commit history across a long-running branch that gets merged into another long running branch? It's always a one-way merge, from integration into production branch, for CI to deploy the update.
We seem to have an issue merging pull requests which are from forks like here and here. Creating pull request from branches is totally fine and is being triggered by travis ci. Is there some settings which needs to be set for the travis CI? See the travis file here. Thanks.
Answer from travis team:
The checks on the links are branch builds. For them to work, the PR author needs to set up Travis integration for their repo, too, with travis-ci.com, and run a build for the tip of the PR branch. It is this build that the PR UI is “waiting for the status to be reported” of.
The check that would run in your repo is the PR build. It runs on a “merge preview” commit that Github autogenerates for PRs.
The types of the checks to run you configure in branch protection settings at Github.
I have a weird issue. Travis OSX builds keep failing because a Jasmine unit test doesn't pass. But, this ONLY happens for commits against the main GitHub repo's master branch. Forked repos, PR's on the main repo, etc do not have this issue. Here are a couple of scenarios:
I sync local master from upstream master and push. Travis build fails.
I make a change, literally any change such as adding a random character to readme.md, commit and push, and the build passes.
I open a PR, the PR build passes
The PR is merged to upstream master, the build fails
There are no issues when running the unit tests locally, so I can only pin it as a GitHub and/or Travis issue. Tried clearing the caches in Travis and did not help. I scrolled through the raw logs side-by-side from a failed and passing build and they were fairly identical, at least nothing I wouldn't expect to be different.
So kind of at a loss here on what to do. Any suggestions?
https://github.com/Glavin001/atom-beautify/blob/master/.travis.yml
This was not an issue specifically with the master branch.
The issue was caused by the Travis environment variable, TRAVIS_COMMIT_MESSAGE. When you merge a PR on GitHub, the default commit message has a "message" and a "description", separate by a line break. Having that line break in the TRAVIS_COMMIT_MESSAGE caused path issues with Ruby and/or Rubygems.
This was resolved by blanking out the environment variable by adding the below to our .travis.yml in the before_install step at the very beginning:
- export TRAVIS_COMMIT_MESSAGE=""
Here is my workflow:
Branch from master
Commit and push the branch to github
Create a PR (1) from the branch to master
Quickly create and merge a PR (2) for the same branch to an integration branch for manual QA
When I do this, travis builds get fired for both PRs (the first to master, to second to a qa branch). The tests pass on the former and fail on the latter because the PR is already closed.
I am ok with that particular behavior, but I noticed that the first PR (1) gets marked as bad according to travis because the test failed on the other PR (2). When I follow the integration link on the PR (1) to the failed travis build, the build references the other PR (2) in the merge ref: +refs/pull/2/merge. Very specifically, it's the continuous-integration/travis-ci/push that is marked as errored. The continuous-integration/travis-ci/pr is ok.
If I go to the Pull requests tab within travis-ci, the expected statuses are presented: PR #1 passed, PR #2 errored.
Have I configured things wrong, or is this a bug in the integration where it's tagging the wrong PR with the build failure (perhaps because they happen to share a source branch)? My only recourse for the moment is to run another build for PR #1 so that the github Open PRs tab shows me and my coworkers the reassuring checkmark.
When pushing to a pull request, there are always two builds going on on travis-ci displayed in the github pull request view:
continuous-integration/travis-ci/pr
continuous-integration/travis-ci/push
When the branch has been created from master, which stays unmodified by others commits, this triggers two times the same build. Is there a way to do only one build?
That's probably because that PR is from another branch inside the same repo. The /pr build is for all PRs which can sometimes be from another repo, while the /push part is because this commit was part of this repo.