bintray deployment

[klemens-morgenstern]

Heya, I'm not sure if you are aware of that but you can use bintray as a debian-source, i.e. add it to your /etc/apt/sources.list. Here are a few more details on that. I think there's something similar for rpm.

That would be great, because then you could even add a go-github-release package that just pulls in all your tools, and it would be insanely easy to set that up in my build environment. Btw. deploying to bintray is as easy as to github releases with travis/appveyor.

[mh-cbon]

yup indeed its pretty cool!

And the OSS plan is really fair, https://bintray.com/signup/oss,
its definitely something to mention.

Thanks for that.

[solvingj]

Yes, it would be great if you could post the go-bin-deb and go-bin-rpm to respective bintray repos. IN the meantime I'll be adding them to my own so that I can use them in my travis build directly.

[solvingj]

@mh-cbon any chance you would want to change this release process to be centered around publishing to Bintray repo's instead of creating repo's on GH-pages. While a very clever use of GH-Pages, it seems like quite a bit of a hack to me.

[joeblew99]

If you want to add another release endpoint for Bintray, make it a plugin, so other release endpoints can also be implemented.

[mh-cbon]

@mh-cbon any chance you would want to change this release process to be centered around publishing to Bintray repo's instead of creating repo's on GH-pages. While a very clever use of GH-Pages, it seems like quite a bit of a hack to me.

If you want to add another release endpoint for Bintray, make it a plugin, so other release endpoints can also be implemented.

deploying to bintray is as easy as to github releases with travis/appveyor.

https://docs.travis-ci.com/user/deployment/bintray/
very much like
https://github.com/mh-cbon/gh-api-cli/blob/master/.travis.yml#L46

---

That would be great, because then you could even add a go-github-release package that just pulls in all your tools, and it would be insanely easy to set that up in my build environment.

same idea as @suntong, he wanted to setup ppa so he could put all his programs into one repo.

---

anyhow, please consider there are two topics here,

1st is to update the procedure (this repo) to use bintray as release endpoints for source package repository (yum/apt).

2nd is to merge those tool under one repo to provide a simpler way to install them all. On that last topic i would like to bring your attention on a concern i have, neither yum/apt are strong dependency manager (AFAIK!). There are good to do forward follow up (take last version and apply it), to my knowledge they can also lock a version, but none of them will help you to lock version on a per project basis with fine selectors, which is a must have in my opinion for this kind of workflow. About windows i will not put too much hope into chocolatey to do it right.

https://github.com/GetStream/vg#advantages-over-vendor-directory

You can pin versions of executable dependencies, such as linting and code generation tools.

[solvingj]

Please just let us know if you plan on setting up your tools to publish to Bintray repos (it really is easy). We're already publishing your packages as binaries to our own Bintray repos, but everyone prefer's packaging from the author.

In either case, it's trivial to make a "go-github-release" package that pulls in the rest. I would do it by adding appveyor/travis recipe's to this repository which generate rpm/deb/nupkg which contain nothing but perhaps the README and License. Then, I would have each of those transitively depends on each of the relevant packages. So...

go-github-release.rpm would depend on:
go-bin-rpm.rpm
changelog.rpm
emd.rpm
gump.rpm

go-github-release.deb would depend on:
go-bin-deb.deb
changelog.deb
emd.deb
gump.deb

go-github-release.nupkg would depend on:
go-msi.nupkg
changelog.nupkg
emd.nupkg
gump.nupkg

Also, as a side-note, I've found no value in releasing go-bin-rpm in .deb format since you can't actually build an RPM on a debian system, and vice-versa for packaging go-bin-deb in .rpm format.

[mh-cbon]

Also, as a side-note, I've found no value in releasing go-bin-rpm in .deb format since you can't actually build an RPM on a debian system, and vice-versa for packaging go-bin-deb in .rpm format.

true!

---

Are those repo public ? I m ok to link to them in the quick terms, on longer terms,

• the procedure includes bintray and is usable to generate those repo, thus link to a [bintray repo for this repo].
• this repo has a travis file with the necessary scripts to generate all the things (? see questions)

Questions
How will the meta repo go-github-release.rpm be updated when emd.rpm is updated ?
Is it needed to trigger a re build of go-github-release.rpm after emd.rpm ?
Or maybe, there s a smart solution ?

[solvingj]

Sure, I'll make some adjustments to the packages and post the links here when done.

I believe RPM/DEB/NUPKG all use latest version of a dependency if no version operators are defined.

[mh-cbon]

you can now use those respective commands,

windows

  - choco source add -n=mh-cbon -s="https://api.bintray.com/nuget/mh-cbon/choco"
  - choco install changelog gh-api-cli go-msi -y
  - refreshenv

https://bintray.com/mh-cbon/choco

debian

  - sudo add-apt-repository 'deb https://dl.bintray.com/mh-cbon/deb unstable main'
  - sudo apt-get -qq update
  - sudo apt-get install --allow-unauthenticated changelog go-bin-deb fakeroot

https://bintray.com/mh-cbon/deb

redhat

- sudo curl -s -L https://bintray.com/mh-cbon/rpm/rpm > /etc/yum.repos.d/mh-cbon.repo
- sudo dnf install go-bin-rpm changelog rpm-build -y --quiet

https://bintray.com/mh-cbon/rpm

see also #21

HTH

ping @suntong

[suntong]

👍

[mh-cbon]

all up to date. Happy if anyone gives any comments.