package.sh swaps to master branch if .git/config contains upstream

[srfraser]

If you wish to test whether package.sh works on a different branch, you must make sure that .git/config does not contain a branch definition, such as:

[branch "logrotation-v2"]
    remote = origin
    merge = refs/heads/logrotation-v2

If this definition exists, then package.sh swaps to the master branch and builds that.

Without that entry, the git pull fails (see below), but package.sh carries on with the current branch, allowing the test package build to work.

There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> logrotation-v2

package github.com/srfraser/telegraf: exit status 1

[sparrc]

thanks for the report, I need to work on a feature to get circleci cross-compiling all pushes (branches and forks)

[sparrc]

@srfraser do you mean that the git pull failure is "expected behavior"? ie, when git pull fails, package.sh builds from the intended branch?

[sparrc]

PS: circleci should now be making debs and rpms, see the "artifacts" tab on any successful build

[srfraser]

Yes, when the git pull fails, it builds from the intended branch. When it succeeds (because the branch config is there), it builds from master.

It would still be useful to test the building of debs and rpms before it reaches circleci

[sparrc]

@srfraser, it appears that go get ./... switches to the master branch IFF there is an upstream branch set.

I don't know why it does that, but the only solution I could come up with is to unset the remote branch before running that command, and log a warning that it happened. Let me know what you think (see referenced commit)

[srfraser]

There could be an optional argument to package.sh, specifying the branch. If not given, set to master, then after go get ./... then git checkout branchname. It might be more work than desired for this use case, though.

[sparrc]

I agree but I think it's a bit too much for this use-case, as it stands the script doesn't really have any arg parsing, I would rather keep it simple, especially since you can now get the .deb and .rpm files via circle