[ANN] [HOWTO] go-github-release: release, package, deploy for windows, rpm, deb with ease!
241 views
Skip to first unread message
mhhcbon
Jul 24, 2016, 12:18:42 PM7/24/16
to golang-nuts
Hi,
After some efforts and lots of reading,
i finally have the cool release flow i was looking for my own usage and purpose.
I sum it and share it here https://github.com/mh-cbon/go-github-release
Initially i was looking for the good automated, re usable practices to release a go package,
i have ended into a feature complete release flow to deliver my software as deb/rpm/msi installers.
I have improved my ability to maintain a changelog,
and reproduced functionality i used to know in other programming languages.
While this is perfectible, i believe it s a nice start.
I hope you ll enjoy it and find interest into it to to release your packages and software.
~~Happy coding!
After some efforts and lots of reading,
i finally have the cool release flow i was looking for my own usage and purpose.
I sum it and share it here https://github.com/mh-cbon/go-github-release
Initially i was looking for the good automated, re usable practices to release a go package,
i have ended into a feature complete release flow to deliver my software as deb/rpm/msi installers.
I have improved my ability to maintain a changelog,
and reproduced functionality i used to know in other programming languages.
While this is perfectible, i believe it s a nice start.
I hope you ll enjoy it and find interest into it to to release your packages and software.
~~Happy coding!
Tong Sun
Jul 25, 2016, 12:40:49 PM7/25/16
to golang-nuts
Looks good, Thanks.
This is for a single-exe release right?
Any plan to have share lib support for multiple-tool releases? I.e., to allow many small tools written in GO to use the same shared lib, instead of each carrying the full set of Go libs.
mhhcbon
Jul 25, 2016, 4:30:44 PM7/25/16
to golang-nuts
This is for a single-exe release right?
A tiny bit more as you can have extra files along your bin,
setup icon for menu launchers,
define env variables,
and for deb/rpm have pre/post script where you can install services or do more fun stuff.
Msi support is definitely missing that last feature.
setup icon for menu launchers,
define env variables,
and for deb/rpm have pre/post script where you can install services or do more fun stuff.
Msi support is definitely missing that last feature.
Any plan to have share lib support for multiple-tool releases?
A totally different story imho, it was not my initial goal.
I really wanted to be able to share those software with non go world,
and this is fulfilled, almost. Not the brightest way, a way that work.
I don t have experience with c programming (which heavily uses that feature)
and their deployment methods/difficulties on unix friendly platforms,
as a result i have poor general knowledge and experience of those problems.
(does windows support that feature too ? I don t even know that..)
So basically nop.
Also note that preparing SRPM, or DEBS (S stands for Source)
are way different than their counter binary part i provided here.
I also think that because of historical reasons, you d better go with a makefile,
dep, rpm, aur heavily relies on it when it come to build the final executable on the final machine.
(then, the q is, how to not have to maintain multiple makefile
for the various target systems, and how to handle that for windows. No clue.)
Now i look to that
https://deferpanic.com/blog/linking-to-a-precompiled-go-lang-library/
or this http://blog.ralch.com/tutorial/golang-sharing-libraries/
I wonder if it is up to date ?
Two questions i have reading this,
does a pre compiled binary can include at runtime a pre compiled library ?
Said differently, does the final exe requires to be compiled on the final system ?
Or, can it be simply shipped as a pre compiled file and include only some symbols
to the dependents libraries to be resolved JIT on the final system ?
In both ways, compiling on the target system, or pushing only a binary with appropriate symbols,
where will it look for this libraries on the system (PATH?) ?
Thus, is this a per system/distrib responsibility, or is it a per language responsibility to define an host directory ?
anyways, as you can see, i have more questions than answers on that topic,
as of today, i m not on the page to achieve such job.
I really wanted to be able to share those software with non go world,
and this is fulfilled, almost. Not the brightest way, a way that work.
I don t have experience with c programming (which heavily uses that feature)
and their deployment methods/difficulties on unix friendly platforms,
as a result i have poor general knowledge and experience of those problems.
(does windows support that feature too ? I don t even know that..)
So basically nop.
Also note that preparing SRPM, or DEBS (S stands for Source)
are way different than their counter binary part i provided here.
I also think that because of historical reasons, you d better go with a makefile,
dep, rpm, aur heavily relies on it when it come to build the final executable on the final machine.
(then, the q is, how to not have to maintain multiple makefile
for the various target systems, and how to handle that for windows. No clue.)
Now i look to that
https://deferpanic.com/blog/linking-to-a-precompiled-go-lang-library/
or this http://blog.ralch.com/tutorial/golang-sharing-libraries/
I wonder if it is up to date ?
Two questions i have reading this,
does a pre compiled binary can include at runtime a pre compiled library ?
Said differently, does the final exe requires to be compiled on the final system ?
Or, can it be simply shipped as a pre compiled file and include only some symbols
to the dependents libraries to be resolved JIT on the final system ?
In both ways, compiling on the target system, or pushing only a binary with appropriate symbols,
where will it look for this libraries on the system (PATH?) ?
Thus, is this a per system/distrib responsibility, or is it a per language responsibility to define an host directory ?
anyways, as you can see, i have more questions than answers on that topic,
as of today, i m not on the page to achieve such job.
mhhcbon
Jul 25, 2016, 4:58:14 PM7/25/16
to golang-nuts
A last though on that topic,
fedora and ubuntu are now pushing new package formats (flatpack / snap).
(sarcasm, Once again everybody s doing its own sauce)
I m not clear about flatpack, but snap is definitely a binary package format.
Let s see what will happen in coming releases.
fedora and ubuntu are now pushing new package formats (flatpack / snap).
(sarcasm, Once again everybody s doing its own sauce)
I m not clear about flatpack, but snap is definitely a binary package format.
Let s see what will happen in coming releases.
mhhcbon
Jul 30, 2016, 12:13:52 PM7/30/16
to golang-nuts
Hi,
quick update to announce several updates.
* simplified appveyor / travis ci scripts. At the cost of some assumptions. If you are into a specific case you can still roll out your own scripts.
* Added support to create RPM repositories hosted on gh-pages
So you can provide a command like this to the end user to install and keep your software up to date,
So you can provide a command like this to the end user to install and keep your software up to date,
The end user can now run a simple command to your install software
Looks like this https://github.com/mh-cbon/gh-api-cli/releases/tag/3.0.0
~~ enjoy
quick update to announce several updates.
* simplified appveyor / travis ci scripts. At the cost of some assumptions. If you are into a specific case you can still roll out your own scripts.
* Added support to create RPM repositories hosted on gh-pages
So you can provide a command like this to the end user to install and keep your software up to date,
* Added support to create DEB/ubuntu repositories hosted on gh-pages
So you can provide a command like this to the end user to install and keep your software up to date,
* Added support to generate chocolatey packages of your msi builds
The end user can now run a simple command to your install software
* gh-release are now created with a the content of the changes for the new version
~~ enjoy
Reply all
Reply to author
Forward
0 new messages