Setup travis

[octonato]

Refs #3

[octonato]

This is basically a copy of the one we use in akka-persistence-jdbc without the cross-compilation.

And without whitesource and paradox

[ignasi35]

LGTM except for a doubt on the publish condition

[ignasi35]

Hmmm, publish on a push to master? (even if there's no tag)

[octonato]

also the akka-persistence-jdbc leftover

[octonato]

I'm comparing this to akka-grpc, it has branch = master AND type != pull_request.

I guess what is happening here is that when you create a tag in GitHub, it's a push to master. So, either type = push or type != pull_request

[ignasi35]

Hmm, pushing a tag upstream is a push to master? What if the tag is on stable branch 1.5.x?

[ignasi35]

Ah, you mean when you create a tag in GitHub in GitHub in particular... I see. 🤔 I have no idea.

[ignasi35]

I still find somethings weird on the conditon ( ( branch = master AND type = push ) OR tag =~ ^v ) but if you copied it from elsewhere and it works there we can go ahead and fix it later.

[octonato]

Yes, that's what I mean. But I think you spotted something that we were not aware of.

This is an OR condition. So, either we are publishing because adding a tag triggers a push on master (which is what I think it's happening) or we publish because there is a tag (which explain how we can publish for other branches).

I took it from akka-persistence-jdbc. It was added by Ennu. Alpakka projects are doing the same and akka-grpc as well.

@ennru / @raboof, can you shed a light on it?

I think the right condition should be:
if: repo = akka/akka-projection AND tag =~ ^v

[ennru]

master is there to do the snapshot releases on every merge to master.

[ignasi35]

@ennru that needs a bit more setting up, right? I mean, we'll probably need sbt-dynver, maybe some extra setting in the publishing logic?

BTW, I'm 100% in favor of sbt-dynver and publishing all commits in master to a snapshots repo.

[ennru]

This is required (as the comment states) as dynver and MiMa can get problems without it (Only shows when there is a lot of commits between versions).

[octonato]

This was failing. That's why I removed. I guess there are some pre-conditions in the repo before you can call fetch --unshallow.

I still need to investigate it. Maybe @dwijnand can shed some light on it.

[dwijnand]

$ git clone --depth=50 https://github.com/akka/akka-projection.git akka/akka-projection
...
$ git remote set-branches --add origin master && git fetch --unshallow
fatal: --unshallow on a complete repository does not make sense
The command "git remote set-branches --add origin master && git fetch --unshallow" failed and exited with 128 during .

You can make that

[ $(git rev-parse --is-shallow-repository) = true ] && git fetch --unshallow

[ihostage]

Try to use Travis settings:

git:
  depth: false # Avoid sbt-dynver not seeing the tag

[octonato]

@ihostage, are you saying what this Travis option makes the git fetch --unshallow redundant?

[octonato]

To be honest, I think I prefer:
[ $(git rev-parse --is-shallow-repository) = true ] && git fetch --unshallow

Simply because if depends on git and not some Travis impl.

[ihostage]

It says Travis itself 😄
https://docs.travis-ci.com/user/customizing-the-build#git-clone-depth

Some operations on the repository, such as common automated code review scripts (e.g. Pronto for Ruby), may fail due to the limited git clone depth, not being able to access all the objects in the repository. Removing the depth flag, or running git fetch --unshallow might solve the issue.

[ennru]

Why not Dynver?

[octonato]

See #26