Add initial travis CI support

[saulshanabrook]

To add travis CI builds you need to create a Travis account with your github, and enable this repository.

I have disabled running lein check because it currently fails, but lein test does pass. Once this is added, we can add more advanced linting (#163) and doc generation (#164)

[saulshanabrook]

@lspector Does this still sound good to you? Do you want any help setting it up in travis? I can't do it myself since I don't have write access to this repo.

[lspector]

@saulshanabrook Yes this still sounds good to me but yes, I'd like help. The getting started instructions look mostly self explanatory (with a few things that I hope will be obvious when I see the indicated pages, etc.) but with one major exception: What exactly do I put in .travis.yml?

[saulshanabrook]

This PR contains a proper .travis.yml (at least at first) I will add other PR's with more advanced things in it (for doc generation) once this gets accepted. So if you:

1. enable travis support for this repository
2. merge this PR

then it will run on all future PR's and on master.

[lspector]

For step 1 you mean only steps 1 & 2 of http://docs.travis-ci.com/user/getting-started/#To-get-started-with-Travis-CI%3A ?

For step 2, do I do the full process under Merge Changes into Mater at https://gist.github.com/thelmuth/1361411, or does travis make this different?

[saulshanabrook]

Yep just steps 1 & 2. I would just click the merge button on this pull request

[lspector]

But then the version number won't be bumped... so I should proceed with the rest of the process, right? And then the travis stuff will make something different happen during that process? What and when? Would it be simplest for us to discuss this and maybe even do it live during our next meeting?

[saulshanabrook]

Well for now the version number doesn't really need to be bumped, since this isn't changing any code, this is just adding testing support, so this version wouldn't be any different.

Travis doesn't change your process yet. All it would do, if you merged this and enabled it, would be to add running lein test after every commit to master and add a status badge on the readme that shows whether this command is failing or not.

Once this is merged, then I can add other features to travis, like the auto-releasing to clojar on every git tag and auto generating docs.

Sorry I don't know if I am doing a very good job at explaining this, is it making any sense?

[lspector]

I don't know what others do, but I think I'd want to bump the version anyway, since it doesn't seem right to have repos around that have the same version numbers but are different from each other in any way, regardless of where the differences are.

Thanks for the explanation about what would(n't) change in the update process from this change alone.

I'll do it soon.

[lspector]

Tried, failed, and am now stuck mid process! Please help...

I enabled travis support on the repository.

Then I accepted the merge request.

Then I tried to follow the rest of the standard process for merging the new version into my local master, bumping the version, and re-pushing, etc... but got stuck with a git error I've never seen before and am not sure how to fix. I made one typo along the way (forgetting a -m in the tagging line), but I thought the following line fixed it... Not sure if that's related. Following is the transcript from my Terminal:

MacBook-Pro-2:Clojush leespector$ git fetch origin
remote: Counting objects: 5, done.
remote: Total 5 (delta 2), reused 2 (delta 2), pack-reused 2
Unpacking objects: 100% (5/5), done.
From github.com:lspector/Clojush
0cceb12..225a118 master -> origin/master
MacBook-Pro-2:Clojush leespector$ git merge origin/master
Updating 0cceb12..225a118
Fast-forward
.travis.yml | 8 ++++++++
README.md | 2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 .travis.yml
MacBook-Pro-2:Clojush leespector$ emacs project.clj
MacBook-Pro-2:Clojush leespector$ git add .
MacBook-Pro-2:Clojush leespector$ git commit -m "Version bump."
[working b1ac26e] Version bump.
1 files changed, 1 insertions(+), 1 deletions(-)
MacBook-Pro-2:Clojush leespector$ git tag -a v2.0.39 "Add initial travis CI support."
fatal: Failed to resolve 'Add initial travis CI support.' as a valid ref.
MacBook-Pro-2:Clojush leespector$ git tag -a v2.0.39 -m "Add initial travis CI support."
MacBook-Pro-2:Clojush leespector$ git push origin master
To [email protected]:lspector/Clojush.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:lspector/Clojush.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'non-fast-forward'
section of 'git push --help' for details.
MacBook-Pro-2:Clojush leespector$

[saulshanabrook]

Hm.... I am not sure, that seems like it would have worked properly. Maybe try git pull --rebase origin master and the git push again?

[saulshanabrook]

Good news is the travis part seemed to work: https://travis-ci.org/lspector/Clojush

[lspector]

I vaguely remember rebase being connected to scary git weirdness. I'm going to see if others in the group have any advice on this.

[saulshanabrook]

Git rebase will rewrite your history, so some people consider it scary. I find it very helpful in certain circumstances. Basically if I have made local changes and someone else has made remote changes, I can rebase against the remote and it basically takes my local only commits and smooshes them on top of whatever the last remote commit was.

[thelmuth]

The only reason I can think of why this wouldn't be a fast-forward for master is if Lee didn't have merged in some changes that happened on the GitHub repo that he didn't merge in before this process. This could happen if, for example, he had merged a pull request previously using the GitHub interface instead of the command line, and then did not merge that request into his local repo.

I would try something like this:

git pull (OR IF YOU DON'T HAVE A DEFAULT REMOTE: git fetch origin; git merge origin/master)

That might give you some merge conflicts since you've changed things in master first. If so, fix those and commit. Then try pushing again.

[lspector]

Wait... I don't understand the part in parentheses. Should I try git pull?

[lspector]

The stuff @thelmuth wrote in parentheses is what I did already, on the way to getting the error... Should I really do it again? Or git pull?

[thelmuth]

git pull is equivalent to git fetch origin; git merge origin/master. So, either should work fine. I'd try them again.

I have no clue what travis is, but is it possible it is changing either Lee's repo or the GitHub repo on its own?

[saulshanabrook]

Nope not possible at the moment.

Technically possible it could change github repo (i think i am unsure exactly what permissions it asks for) but that is only if it was doing something it wasn't supposed to. It didn't change any commits it looks like: https://github.com/lspector/Clojush/commits/master

There is no way it could change his local repo

[lspector]

MacBook-Pro-2:Clojush leespector$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch.working.merge' in
your configuration file does not tell me, either. Please
specify which branch you want to use on the command line and
try again (e.g. 'git pull ').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
use something like the following in your configuration file:

[branch "working"]
remote = <nickname>
merge = <remote-ref>

[remote "<nickname>"]
url = <url>
fetch = <refspec>

See git-config(1) for details.

[lspector]

I guess that means I try the other way; hold on...

[lspector]

MacBook-Pro-2:Clojush leespector$ git fetch origin
MacBook-Pro-2:Clojush leespector$ git merge origin/master
Already up-to-date.

Does that shed any light?

[thelmuth]

If it's up-to-date, I don't see why git push wouldn't work. Give it another try?

[lspector]

MacBook-Pro-2:Clojush leespector$ git push origin master
To [email protected]:lspector/Clojush.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '[email protected]:lspector/Clojush.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'non-fast-forward'
section of 'git push --help' for details.

[thelmuth]

Yeah, not sure what's going on. Could be the travis.

I'd go ahead and try Saul's suggestion of rebasing. Seems pretty safe in this instance. Though, you probably only need to do git rebase origin/master, since you've already fetched origin.

[lspector]

MacBook-Pro-2:Clojush leespector$ git rebase origin/master
Current branch working is up to date.

[lspector]

Hmm. That led me to do git status and I see that I'm on branch working, rather than master which is where I thought I was. Does that explain anything?

[thelmuth]

That explains everything :)

[thelmuth]

Always do git status before, during, and after everything you do.

[thelmuth]

Sounds like you probably need to start from the beginning after changing to your master branch.

[lspector]

Okay, I think we're in good shape now.

Switched to my master branch, did the whole thing again, didn't screw up the git tag command (might that have been another contributor to the problem?), but was then informed "fatal: tag 'v2.0.39' already exists"... so bumped up to 2.0.40, went back part of the minefield (er, procedure) where I edit the version number and continued again from there... And all seems to have succeeded. Except I assume I should nuke that working branch and create a new one...

Thanks, and I think all is well now... although I sure am looking forward to this process being more automated and less error prone (which it sounds like travis should eventually give us, along with the auto-testing and auto-doc etc.).

[thelmuth]

Don't nuke your working branch if it has stuff you're working on! In fact, it obviously has something you've changed outside of master, since it wouldn't push cleanly.

Otherwise, sounds good!

[lspector]

Actually, I only renamed it. So now I can diff it with the new working branch that I made after doing the merge... and it says that the only difference is the version number.

[saulshanabrook]

Glad it all worked out!