Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking upgrades using upgrades.syncthing.net instead of github.io pages #77

Closed
xor-gate opened this issue Aug 4, 2018 · 15 comments
Closed
Assignees
Milestone

Comments

@xor-gate
Copy link
Member

xor-gate commented Aug 4, 2018

So we should probably move the current Sparkle Update feed to the auto-generated appcast.xml. And create some graph of the HTTP GET requests. The go script currently build during CI build should be easy to add (https://github.com/syncthing/syncthing-macos/blob/develop/script/ghreleases2appcast.go)

Info.plist:

	<key>SUFeedURL</key>
	<string>https://xor-gate.github.io/syncthing-macosx/appcast.xml</string>

To:

	<key>SUFeedURL</key>
	<string>https://upgrades.syncthing.net/syncthing-macos/appcast.xml</string>

Also tracking the download counter of the latest release (e.g with telegraf) is nice to see the amount of downloads.

 > curl -s https://api.github.com/repos/syncthing/syncthing-macos/releases/latest | grep download_count
      "download_count": 4066,

telegraf.conf

[[inputs.tail]]
   files = ["/Users/jerry/src/github.com/xor-gate/syncthing-macosx/script/log/upgrades.xor-gate.org.access.log"]
   pipe = false
   watch_method = "inotify"
   data_format = "grok"
   from_beginning = false
   grok_patterns = ["%{COMMON_LOG_FORMAT}"]

[[inputs.http]]
  username = "xor-gate"
  password = "---OBVUSCATED---"
  urls = ["https://api.github.com/repos/syncthing/syncthing-macos/releases/latest"]
  data_format = "json"
@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

screen shot 2018-08-04 at 18 31 33

@calmh
Copy link
Member

calmh commented Aug 4, 2018

So I'm not super keen on the tracking aspect - we don't really do much of that on the Syncthing side except for the explicitly opt-in, and except for counting requests to upgrades.s.n (https://monitor.syncthing.net/dashboard/db/web-sites), which this would become a part of.

That said, it's now live on https://upgrades.syncthing.net/syncthing-macos/appcast.xml, with some tweaks to the script (there is a branch).

The release note formatting thing fails a bit, producing some ugly code, not sure how much it matters.

From a "is it looking professional looking" standpoint I'm not super impressed by having the bundle signed by someone going by the signifier "virusman" - no offence intended, @virusman...

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

I think the signature itself doesn't contain my nickname, but I'm ok if someone else wants to build and sign instead.

@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

@calmh I agree with

From a "is it looking professional looking" standpoint I'm not super impressed by having the bundle signed by someone going by the signifier "virusman" - no offence intended, @virusman...

But this is currently the only one who stands up to sign the dmg or else macOS chokes and doesn't want to start the app. If we sign it with a new/different key and distribute it people need to install it again by hand because it is not allowed for security reasons to change signing keys between upgrades.

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

Yeah, the certificate and signature only show my real name. Or is the presence of my handle in general on Github and elsewhere an issue?

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

I've built a new .dmg, let me know what you decide on. If I create a new release from a tag, I think it will show me as an author of that release on Github.

@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

Thats no problem for me. You are also priviledged to do so. Just create the tag (as prerelease) and I will create the changelog in the release page.

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

Hmm looks like I can't push a new tag, Github returned 403.

@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

I have unprotected the master and develop branch (for now). Could you check again. Possibly this should not be necessary for pushing tags.

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

Still the same error: remote: Permission to syncthing/syncthing-macos.git denied to virusman.

@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

Thats just weird, you have been added as collaborator. Have you accepted it? No clue why it doesn't work >_<

@virusman
Copy link
Contributor

virusman commented Aug 4, 2018

Looks like a release can be created without an existing tag anyway, so I created a draft and uploaded the .dmg there: https://github.com/syncthing/syncthing-macos/releases/tag/untagged-3b342874e15f3f29dc7d

@xor-gate
Copy link
Member Author

xor-gate commented Aug 4, 2018

Yeah that seems legit.

@xor-gate
Copy link
Member Author

xor-gate commented Aug 9, 2018

Everything is in place, @calmh deployed it in production. On next release it loads the appcast from the upgrades.syncthing.net. I will close this issue as there is no more work to be done. Feel free to comment if there is anything to share.

@xor-gate xor-gate closed this as completed Aug 9, 2018
@xor-gate
Copy link
Member Author

xor-gate commented Nov 7, 2018

I'm not sure but we can break the release once again because we now can take the signed build from https://build.syncthing.net ? I just need to upload the artifact to github and add a notice.

xor-gate added a commit that referenced this issue Nov 7, 2018
* syncthing/Scripts/syncthing-resource.sh: Bundle with 0.14.47

* Get rid of syncthing/Scripts/syncthing-inotify-resource.sh as filesystem change notifications are builtin to syncthing since v0.14.47

* Delay reconnect attempts if the server returned an error (#47)

This should fix high CPU usage issue when API key is invalid. Partial fixes #46.

* Bump syncthing resource to v0.14.48 (#55)

* syncthing/STApplication.m: Sort folders submenu ascending (fixes #49) (#53)

* syncthing/STApplication.m: Sort folders submenu ascending (fixes #49)
* syncthing/STApplication.m: Fix review comment of @virusman

* Use CocoaPods for Sparkle framework dependency (fixes #57) (#60)

* Update syncthing resource to v0.14.49 (#64)

* Update syncthing resource to v0.14.49
* syncthing/Scripts/syncthing-resource.sh: Use new tarball name

* Adjust event request timeout (fixes #65) (#66)

This sets the event request a bit longer and, more importantly, informs
Syncthing of the timeout. The result is that the request returns
successfully without events, and we don't get a timeout error.

* Refactor HTTP(S) handling (fixes #24)

This moves event getting into the XGSyncthing library, while also
refactoring it to use NSURLSession, a delegate for allowing local TLS
certificates, and proper parameters.

The delegate simply skips HTTPS certificate checking on hosts called
"localhost", "127.0.0.1", or "::1". I think this is what most people
would want from this tool.

* Remove #24 from README too

* README.md: Update to use new URLs (#67)

Also add @calmh to AUTHORS.md

* Move LocalhostTLSDelegate files accidentally committed at root (#70)

* Generate appcast.xml from github releases (#63)

* script/ghreleases2appcast.go: Initial working github releases to sparkle framework appcast.xml converter (resolves #62)

* Activate existing windows for About/Preferences (fixes #72) (#73)

* Add daemon process handling (fixes #48) (#71)

* Add new submenu with status of the syncthing service
* Cleanup some code

* Copy executable from bundle (fixes #37) (#76)

This copies the bundled executable before executing it, if the target
executable doesn't already exist. This has several desirable properties:

- We do not mess up the application bundle by letting Syncthing upgrade

- The user can revert an undesired upgrade by deleting the binary and
  restarting the wrapper.

The binary is stored in ~/Application Support/Syncthing-macOS because I
don't want to put it in Syncthing's config directory. That directory is
in principle managed by Syncthing and we can't be sure it won't be
removed or something.

* Prepare for v0.14.49-1 release (#75)

* syncthing.xcodeproj/project.pbxproj: Rename PRODUCT_BUNDLE_IDENTIFIER for Sparkle updater (see #74) (#79)

From com.github.syncthing.syncthing-macos back to com.github.xor-gate.syncthing-macosx to fix Sparkle update issue in #74.

* script/ghreleases2appcast.go: Use working blackfriday.v1 (see #77) (#78)

* script/ghreleases2appcast.go: Changes for upgrades.s.n deployment (#80)

Basically, don't alter the download URLs for now, indent the XML for
readability.

* Fixup project move leftovers and update some documentation (#81)

* Fixup project move leftovers and update some documentation and contributing
* Cleanup xcode project with useless xgsyncthing target
* README.md: Add note about homebrew cask (ref #23)

* readme: Update contribution guidelines link (fixes #83)

* Bump syncthing resource to 0.14.50

* Use latest syncthing v0.14.51 resource

* CocoaPods: Manual patch EXPANDED_CODE_SIGN_IDENTITY: unbound variable #7708 bug

* Use syncthing v0.14.52 resource
@syncthing syncthing locked and limited conversation to collaborators Aug 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants