Repository navigation
Build & distribution system #38
Description
We'd benefit from having a system for push-button build and binary distribution.
Reacted by Robert (Jamie) Munro and David Bourguignon
{{ message }}
We'd benefit from having a system for push-button build and binary distribution.
Activity
tiennou commentedon Feb 14, 2017
I'm on it, I just need to find some time to redo the Travis setup I made in my fork and document it.
tiennou commentedon Feb 16, 2017
Okay, Travis is go now. For the record, its running under the authority of my own account (because lazyness).
I'll ponder the distribution problem a little more, but right now it is thus :
So, if someone has a better idea, I'm open to suggestions.
whitecat commentedon Feb 24, 2017
Does binary distribution mean something that is already compiled and ready to use on mac?
andreif commentedon Feb 24, 2017
@whitecat Yeah, that's how I see it,
dmg-files to be published on homepage/GitHub-releases.whitecat commentedon Feb 24, 2017
Can Travis auto run your build instructions from this website https://github.com/gitx/gitx/wiki/Build-instructions?
whitecat commentedon Feb 24, 2017
To get a Dev ID would you want the app be an individual account or a company one?
tiennou commentedon Feb 24, 2017
Travis can, and is mostly setup now. We just haven't turned on The Switch yet, because there's no automatic update mechanism (i.e. we need to setup a Sparkle feed).
The second point is a good one. Bluntly, I don't want to go through the hassle of building a company just for some certificates. I might register as a dev just for that, but I also might not 😉.
whitecat commentedon Feb 27, 2017
Sadly you have to pay $100 a year and I do not think people will donate enough to make up that cost.
tiennou commentedon Feb 27, 2017
I have found a way to make automated releases (I think, there are many things I'm not sure of but in theory it should work).
As stated earlier, we can use Travis <=> GitHub Releases integration to perform the deployment step. Then it's possible to generate an appcast.xml file from that, using the release metadata kindly provided by Jekyll.
A big caveat is that we might need to kill the
gitx.github.iorepository (actually, now that I think about it some more, that's not true, but I digress). Yesterday, I pushed an updated gh-pages branch with a "prototype" appcast, which is now online here, under the gitx/gitx repo gh-pages branch, under the gitx.github.io repo (yeah it's confusing, hence my point about killing the other one).Another option would be to keep it that way, just keeping what's required by the appcast.xml, which would give us https://gitx.github.io/gitx/appcast.xml as the Sparkle feed URL (that gitx path is hardcoded).
So the release process would be this :
Scripts/release.py), which would perform the "version update dance", commit it, and tag it.Scripts/deploy.py. This would cause our beloved "build artifact" (:wink:) to be packaged in a DMG, and published as a GitHub Release.Is everyone on board with that ? As always, comments and suggestions are more than welcome.
tiennou commentedon Feb 27, 2017
Meantime, I'll be working on that bunch of scripts. Relatedly, are you guys more Pythonistas than Rubyists ? I'm not that well versed in Python, so my vote naturally goes toward Ruby...
nanotech commentedon Feb 28, 2017
Using the gh-pages branch on gitx/gitx is fine, and keeps it together in the same repo.
The Jekyll/Appcast tool Glow exists if that would be useful directly or as a reference.
If adding a release doesn't trigger a Pages rebuild, there's a build request API now that could be called from Travis. For testing builds before general release, maybe have a whitelist that needs to be edited before versions appear in the appcast?
If we write a high-level changelog that isn't just the Git history, that should probably be finished before tagging the release. Including changelog entries as part of feature and bugfix PRs would be a good way of distributing the effort.
The scripts would probably be short enough for the language not to matter too much, so I'd say use what you're familiar with. (I like Ruby myself.)
For the Sparkle DSA signing key, I think it would be a good idea to have a few people (at least @tiennou and @ssp) keep copies of the private key to ensure continuity of update signing in the long-term. Documenting how the keys are managed would be good too. (e.g. stored in Travis, sent to key holders PGP-encrypted, stored encrypted in cold storage.)
andreif commentedon Feb 28, 2017
Use the language which is more convenient to develop with than to use, so you can keep a good velocity. I would personally prefer Python due to easier debugging but if you are more productive with Ruby then sure use it, so we get things done faster.
pvinis commentedon Feb 28, 2017
isn't Travis free for open source?
also, you can look into fastlane. it's basically using ruby and has some helpers. I can help with that too. it's nice fire doing builds.
9 remaining items
apepper commentedon Apr 26, 2018
Any news on this? I would really much appreciate prebuilt versions of gitx.
aterenin commentedon Nov 16, 2019
Any further updates? I've been using a prebuilt version someone uploaded to one of the GitHub issues. GitX is still the best Git GUI out there IMHO - UI/UX is near-perfect for essentially anyone without an ultra-heavyweight use case better handled on command line anyway.
A publicly-released binary would be a big plus, even if it isn't signed and users have to click through System Preferences to open it. Most Git users are savvy enough to know how to do that anyway.
AntonNguyen commentedon Nov 16, 2019
I got tired of waiting for an update to gitx, so I started looking for alternative. Most of them didn't have that key
amendfeature that I love within gitx. That's until I found fork.dev. It's under active development, has a ui similar to gitx, and has cool new tricks like tabs.plan44 commentedon Nov 16, 2019
thanks for that hint. fork.dev really feels like gitx reborn! I only hope the two devs who do this now in their spare time don't get exhausted before they find a business model or decide to OS it ;-)
tiennou commentedon Nov 17, 2019
Thanks for the hint as well, I'll be sure to take a look soon 🤣.
aterenin commentedon Nov 17, 2019
Not to be a snob, but that app isn't open-source, and their logo risks making me hungry in the middle of the day. As far as I can tell, GitX still largely works, as long as one can get it to build on a modern system. What's the issue with creating a release - is something still broken?
tiennou commentedon Nov 17, 2019
The main, underlying issue is that, I'm neither a "modern", or a "professional"
System 7MacOS 8macOS developer, and this is Open-Source 😜.More seriously, the underlying issue has a "big picture" description at libgit2/objective-git#648. The TL;DR is that the homemade 4-arch builds of OpenSSL, needed to get SSH support, is broken on Travis. There has been some work on that front as part of Objective-Git (w.r.t to brewed dependencies mostly, but GitX brings a bunch of signing issues on top of that, and this ends up with stacked build systems, which is never fun to fix on Travis).
I could do a release, but since I'm not in a position to invest time into it… I usually have a tendency to post "private" developer builds from Xcode, when there's a few issues closing, but the actual
publish.pythat does the checking/tagging/building/publishing hits codesigning failures since Mojave, while it's working in Xcode itself.Sorry to vent off like this. It's been somewhat frustrating to not be able to do more releases because OS updates happen to have broken a workflow 😉.
aterenin commentedon Nov 17, 2019
Hey, let me just take a moment here that the effort you've put into keeping GitX alive over the past few years is highly and strongly appreciated! 😀😀
From a quick look at the that page, sounds like quite the issue.
There's something to be said for simply manually tagging a commit, uploading a pre-built binary to the repo by hand, calling it a pre-release in the meantime - at least until the OpenSSL issues are addressed. That way people who develop for platforms other than Mac OS / iOS and who do not have Xcode installed can at least get a binary.
pioug commentedon Mar 25, 2020
Found out today that I was using version of GitX from 2014 😆 So I tried to build a binary from Travis and upload it to GitHub as a release. I just followed the build instructions:
Commit: pioug@002a20f
Job: https://travis-ci.com/github/pioug/gitx/builds/155135323
GitHub release: https://github.com/pioug/gitx/releases/tag/v0
Build archive: https://github.com/pioug/gitx/releases/download/v0/build.zip
I can't tell if the OpenSSL issue is fixed now, I don't know anything about Xcode and MacOS development but I would be happy to help on CI part if that's what you want to achieve.
@tiennou @nanoant @claybridges
GitX is so good 💕 but finding this maintained version plus the binary was a long journey for me 😅 As a web dev I can also help to update http://gitx.github.io/ if needed.
Feuermurmel commentedon Jul 2, 2020
I think now is the time I would like to weigh in on this issue.
First of all, I'm really glad that this app exists. I've tried so many Git GUI apps, paid and free, closed and open-source, and most of them are overloaded with features I don't need or rather use the command line for. GitX really does exactly what I want. On Linux, I mostly use Git Cola and gitk, they do their resepective jobs well but don't really fit into a macOS environment.
I've also seen people I've taught Git struggle with the toolset built e.g. into IDEs like IntelliJ IDEA and VS Code and when I showed them GitX they immediately said "oh, wow, that looks much easier to use!"
I've been using GitX 0.15.1964 dev © Pieter de Bie, 2010 for the past 10 years, fearing that some macOS upgrade or something else will eventually break it. That is, until I found out that a new team has taken over maintaining and improving it in the meantime!
I'm currently using 0.16.2327 dev from 2018, the newest version available on the Releases page. It's a bit buggy and there are some small things I'd be glad seeing fixed, but I still like using it.
Now seeing all of this, I think it's a real shame that the work that has been done in the meantime is not available to most people running GitX. I've inversted an hour or so and wasn't able to produce a working build on my machine. I would certainly not expect a friend I just started teaching Git and some coding basics to be able to produce a build on their own. But we both certainly benefit from the app existing in its current shape!
I see that a lot, possibly annoying work might be necessary to get the current code-base into a shape to again be able to produce regular release builds. Having a fully automated setup for this is ceratinly desired and time well invested. But if this desire to get this release process to work as well as possible is standing in the way of getting any release published at all, then I'm viewing this as effort being wasted.
I can't make a suggestion as to what course of action would be the best even in my oppinion, I don't know what the real hurdles are right now. What I can do, is tell you that I, as a simple user of GitX, would like to see that the continued work on this project is available to users in any form. Even if it means that someone had to produce a build manually in a convoluted way, producing an unisgned binary, rather than seeing the effort being wasted because it's inaccessible to most users.
This is my honest oppinion. I hope I haven't stepped on anyones toes and would like to restate that I'm glad to see all the effort being put into this project, any effort whatsoever. I'm happy for having been able to use this app for so long.
:)
claytonrcarter commentedon Feb 8, 2022
FYI, as of yesterday, pre-built binaries are now available for all pushes to PRs and master, and we now have automated released based on GitHub releases and tags. See #255 #256 #258 and https://github.com/gitx/gitx/releases/tag/0.17
They aren't signed and they don't plug in to Sparkle updates, but they're something.
caifara commentedon Feb 8, 2022
Wow, just upgraded gitx for the first time since 2014 apparently! Thanks @claytonrcarter and anyone else involved!
Adjust download link of latest version.
hannesa2 commentedon Feb 13, 2022
I guess it's obsolete now, because we can build x86_64 and arm64.
Please reopen if it's still an issue