Good to known, as a “test” I always update myself and see if everything went ok with the public release channel. And waiting 15 minutes is not a problem, just two coffee 
Does it alter any of the files/content inside like Google Drive does?
or is it going to be an equal copy?
No alterations.
1 Like
@xor-gate The macOS builder is biting the dust, kicking the bucket, soon to be pushing up daisies. This would be a good time to look into migrating the build to GHA or something else…
You can peek at the mac building happening in GHA for Syncthing, it does a bunch of stuff for the signing etc., and the builds can be pushed to Spaces for download. I can assist with the relevant secrets as needed.
4 Likes
Hi @calmh, I have setup initial github workflow for debug and release builds. You could modify the repository settings/workflow to match the release build with the correct secrets.
The debug build works, but the release build not yet (copied from syncthing).
Thanks!
@xor-gate I’ve done some things, but I’m not sure how it really fits with the build setup. We can discuss…
- I added an environment called
signingwhich contains the secrets in question, currently limited to apply only to thedevelopbranch - I added
environment: signingto the relevant jobs in the build setup, you can see my proposed changes in thebuild-signingbranch - I modified the branch protection of
developto require pull requests (though you, as an admin, can ignore this), otherwise it’s a bit too open
However, looking at it, the environment variables pointing to the signing certificate etc are those expected by Syncthing. But we’re not building Syncthing, are we? Is this picked up by the Xcode build stuff? I’m not certain how it works.
Hi @calmh, everything seems to be in place now. For the project I now also have a release branch. On this branch only the release build and notarize is performed.
Thanks, it worked faster then expected!
Ah good, it works as expected, all done?
1 Like
Yes, all done :-). Thanks for your effort and fast response.
1 Like
@calmh has the macOS builder been deprecated/scrapped/send to the dumpsite from Syncthing teamcity DevOps infrastructure? I have put the two project in pauze and removed the teamcity checks from the github integration in the syncthing-macos git repository. Do you want to keep the two teamcity projects for archival purposes or want them removed one day? The syncthing-macos project only relies on the appcast.xml deployer for Sparkle update. But this is a Linux-enabled build (go tool only).
Kind regards, Jerry
Hello guys. Is there going to be a 1.27.9 release of the macOS bundle? Sorry to pester.
or 1.27.10 …?
I don’t do the syncthing-macos stuff so just a member of the audience here, but, Syncthing itself auto upgrades, right? So you don’t actually need a new syncthing-macos release?
1 Like
No, it doesn’t…
1 Like
No pressure, I receive syncthing release update e-mails. But if @luckman212 did read the changelog it was mostly maintaince work and no feature or bug fixes. I have planned to upgrade Syncthing macOS. And @calmh the syncthing itself has auto updates set disabled via STNOUPGRADE. So only updates are pushed from Sparkle + Github with appcast.
1 Like
Release info:
v1.27.10:
#9455: lib/api tests unreliable, failing ~50% of the time on Fedora Linux
#9499: Data race in fakeFS (testing)
v1.27.9:
build: Update dependencies by @calmh in #9565
gui: Use localised time in duration by @rasa in #9552
gui: Add Filipino (fil) translation template by @acolomb in #9599
So no exciting changing which affect (macOS) usage.
Thanks @xor-gate I didn’t want to pressure. Yes I did read the changelog, I was just raising an eyebrow because .9 was skipped entirely.
Saw the new release, and just want to say thank you @xor-gate
2 Likes
I made this decision long time ago so it is deterministic in versioning also when bug reporting if the wrapper/gui has different version then the runtime dependency (syncthing-daemon). It can be annoying for some, but this approach is “watertight”.