Closed
Description
I would like to integrate a proper process to create real system packages and distribute them via Bintray, than users can just add a deb/rpm repository and got a clean upgrade path.
Beside that we can also publish our releases to a static page or also to Bintray for download.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
metalmatze commentedon Nov 3, 2016
Do we really need deb/rpm? Aren't just docker images enough? Idk, prove me wrong! :)
metalmatze commentedon Nov 3, 2016
drone only has docker images, right?
jhasse commentedon Nov 3, 2016
Gogs is using packager.io, why not reuse that?
tboerger commentedon Nov 3, 2016
Because not everybody is/will use docker.
Packager.io only supports lts versions, beside that the golang packaging can be done much easier than with the overhead of Packager.io.
jhasse commentedon Nov 3, 2016
Okay I don't know enough about Go. But having a solution for Ubuntu 16.04 would be great, as gogs/gogs#3617 didn't get merged :(
tboerger commentedon Nov 3, 2016
To provide packages for any ubuntu/debian/whatever version we can wrap the same binary into the package and just need to adjust the init (sysvinit, systemd) script.
jhasse commentedon Nov 3, 2016
Can we merge the 16.04 packager.io PR and enable gitea on it for the time being though?
lunny commentedon Nov 3, 2016
Both binary and docker are needed.
tboerger commentedon Nov 3, 2016
We don't have enabled anything over there yet, but since this issue is estimated for 1.0.0 I would like to introduce it for our first release.
sbrl commentedon Nov 17, 2016
I also would like binary releases - I don't have a go development environment setup to compile things.
Also, will I be able to upgrade to gitea from gogs? I'd hate to loose my issues etc.
tboerger commentedon Nov 17, 2016
We will have binary releases and hopefully also packages for the major Linux distributions. You don't need to compile anything.
We will also have binaries for the latest master version.
You will be able to directly launch gitea with the Gogs database. If we got database changes they are getting automatically migrated.
sbrl commentedon Nov 17, 2016
Ooh sounds awesome! I'm looking forward to it then ☺
-- Starbeamrainbowlabs (keybase.io/sbrl)
114 remaining items
zeripath commentedon Jan 22, 2020
@evitalis you don't need a script if you build it with the appropriate LDFLAGS.
sapk commentedon Jan 23, 2020
Just thinking of it. FHS path should be default for v2 as it would be a needed breaking change.
zeripath commentedon Jan 23, 2020
I think we need to break that down a bit. There are four kinds of build at present:
FHS by default makes sense for up to 2 of those: release and possibly personal - but at present you can't tell if a personal build is a development build or vice versa. Breaking the development builds would be a very very bad idea.
The Docker should also have its defaults embedded - it's nonsensical to have to require "-c" by default on a docker build we build ourselves.
There's a possibility of changing where we look by default depending on where the binary is placed - but I suspect that might be a bad idea. I guess I'd have to check again what is normal practice for this. (hierarchies of config lookups? - ugh complex)
When I first made the LDFLAGS option work I proposed:
These are non-breaking changes that would not necessarily require waiting for 2.0 - we're just adding a new download option.
An alternative is to add a configure script and make install endpoints - as then it would look "normal" to people used to:
tboerger commentedon Jan 23, 2020
It's absolutely normal to search within predefined paths for configs if you do not provide a flag for a custom path. That's as an example already part of https://github.com/spf13/viper to define multiple standard paths. The current fuckedup behavior of Gitea is totally uncommon.
sbrl commentedon Jan 24, 2020
Perhaps it would be worth putting the release builds into the repos first would be a good 1st step?
azlux commentedon Feb 7, 2020
@sbrl already done on my repo , the build script is store here : https://github.com/azlux/dpkg-deb
As you said, It use directly the release build.
tboerger commentedon Dec 19, 2020
I'm not really involved into Gitea anymore, so I'm closing this issue. If there ist still interest please open a new issue and maybe link to this one for initial discussion. I want to get my issues cleaned up.
fazlerabbi37 commentedon Dec 20, 2020
tboerger commentedon Dec 20, 2020
Just reference this issue on the new one to keep the context. Unsubscribe is not the same as having it in my open issues view on github. And as I can't transfer issues to somebody else it's closed. Beside that, nothing has changed for years...