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.

Sign up for GitHub

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

Jump to bottom

Handle test builds & releases via Travis CI, Publish proper debug builds for Win(XP,7+) and macOS on AppVeyor #200

Merged
merged 1 commit into from
Jun 23, 2020
Merged

Handle test builds & releases via Travis CI, Publish proper debug builds for Win(XP,7+) and macOS on AppVeyor #200

merged 1 commit into from
Jun 23, 2020

Conversation

OPNA2608
Copy link
Member

@OPNA2608 OPNA2608 commented Apr 1, 2020 •
edited

I figured it'd help to handle all releases via (one) CI, so I spent afew days tinkering with Travis CI and came up with this.

This is still a draft, I plan to either replace the development builds on AppVeyor with Windows & macOS debug builds via GitHub Actions or expand on the AppVeyor configuration with a macOS one next - I haven't decided yet what'd make the most sense.
Additionally, during my testing, the Qt fetching part on the Windows builder sometimes fails due to the Qt downloads page seemingly having networking problems. I think caching the fetched & configured Qt builds might help with working around such problems, though I have yet to dive into that.

Sharing this here for feedback & opinions, maybe help with the cache if anyone's feeling lucky.

The working Travis CI jobs + deployment, as of now, can be seen in action here:
https://travis-ci.com/github/OPNA2608/BambooTracker/builds/158645985

And releases page, to showcase the deployment here:
https://github.com/OPNA2608/BambooTracker/releases/tag/v0.4.2

@OPNA2608
Copy link
Member Author

OPNA2608 commented Apr 3, 2020

Added the manually fetched Qt5 components' directories to the cache - the build speed-up is minimal, but it should come in handy in case the Qt5 download page acts flakey again.
Also moved some of the common CI code into a separate top-level directory ci.

Side note: I noticed Travis CI is looking to deprecate the .org domain and move everything to travis-ci.com, along with afew other changes. Maybe you should look into that.
https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com/#existing-open-source-repositories-on-travis-ciorg

@OPNA2608
Copy link
Member Author

OPNA2608 commented Apr 6, 2020

I added debug builds from master via GitHub Actions, you can check them out here.
https://github.com/OPNA2608/BambooTracker/actions

These are unstripped builds, so they're alot larger than release ones, but they should include debug symbols and the Windows builds are configured to open a console window to write their output to. Additionally, they require a GitHub account to download from the Actions page, compared to the freely accessibly artifacts on AppVeyor. I have no strong preference for either though, so if that's a deal-breaker to you I can look into improving the AppVeyor setup with the debug settings and adding a macOS target instead.

What still needs changing are the deployment details in .travis.yml, currently it's configured to deploy to my fork (Should I copy the current credentials or do you want to look into the whole travis-ci.org -> travis-ci.com moving thing while I'm at it?).

Besides that, I think this PR should be ready for now. Let me know what you think, if you see room for improvements somewhere or if there's something you don't like about the proposed changes.

@OPNA2608 OPNA2608 marked this pull request as ready for review April 6, 2020 12:02
@OPNA2608 OPNA2608 changed the title [WIP] Handle all builds & releases via Travis CI Handle all test builds & releases via Travis CI, Publish master debug builds on GitHub Actions Apr 6, 2020
@OPNA2608
Copy link
Member Author

OPNA2608 commented Apr 6, 2020

Oh, I forgot to mention it but I tested all release & debug builds for Windows XP and modern Windows and they launched fine. I'm unsure about & unable to test the macOS builds (to which I added JACK support while I was at it) though, maybe you can test them?
The macOS Legacy build are our current macOS builds, going for biggest compatibility possible. The modern macOS build should be built on a toolchain that supports a macOS system dark mode introduced in 10.14 and is thus limited to macOS 10.14 and up.

@rerrahkr
Copy link
Member

rerrahkr commented Apr 7, 2020

I'm unsure about & unable to test the macOS builds (to which I added JACK support while I was at it) though, maybe you can test them?

Thanks for setting up travis, I can't work on macOS for a while, but I'll check them.

These are unstripped builds, so they're alot larger than release ones, but they should include debug symbols and the Windows builds are configured to open a console window to write their output to. Additionally, they require a GitHub account to download from the Actions page, compared to the freely accessibly artifacts on AppVeyor. I have no strong preference for either though, so if that's a deal-breaker to you I can look into improving the AppVeyor setup with the debug settings and adding a macOS target instead.

There are many people who use dev-build on twitter as for as I look, those does not have a Github account, so I think it's better to publish artifacts on Appveyor. (also need to change Appveyor settings for macOS as you say)

Should I copy the current credentials or do you want to look into the whole travis-ci.org -> travis-ci.com moving thing while I'm at it?

I moved this repository to travis-ci.com, thanks for your information!
https://travis-ci.com/github/rerrahkr/BambooTracker
Would you restore the information about the repository? (note i changed api_key at f47ea5f)

@OPNA2608
Copy link
Member Author

OPNA2608 commented Apr 9, 2020 •
edited

There are many people who use dev-build on twitter as for as I look, those does not have a Github account, so I think it's better to publish artifacts on Appveyor. (also need to change Appveyor settings for macOS as you say)

(Hopefully) Done, see the queued AppVeyor build. The AppVeyor configuration file could prolly be done abit better, but it should work well enough for now.

Would you restore the information about the repository? (note i changed api_key at f47ea5f)

Done². Let me know if this looks fine to you and I'll clean up the commit history abit before it's merged.

@OPNA2608 OPNA2608 changed the title Handle all test builds & releases via Travis CI, Publish master debug builds on GitHub Actions Handle test builds & releases via Travis CI, Publish proper debug builds for Win(XP,7+) and macOS on AppVeyor Apr 9, 2020
OPNA2608
OPNA2608 commented Apr 9, 2020
View reviewed changes
.appveyor.yml
Comment on lines +82 to +83
# Fixes AppVeyor build erroring out...?
echo "=== BUILDING DONE ==="
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why, but this echo here keeps the build from getting stuck without log output after mingw32-make and miraculously erroring out. (Example here.) Maybe AppVeyor thinks it got stuck, or PowerShell does something weird, I don't know.

@OPNA2608 OPNA2608 force-pushed the travis-all-releases branch 3 times, most recently from 362e277 to c615c98 Compare May 5, 2020 13:06
@OPNA2608 OPNA2608 mentioned this pull request Jun 11, 2020
Closed
@OPNA2608
Copy link
Member Author

Checks should succeed once #221 is merged.

With MSVC now being a concern, I'll look into adding a build test for MSVC if this PR is still open when I have more time again.

@OPNA2608
Copy link
Member Author

Forgot some debugging settings and a leftover from testing the other PR, apologies for the extra noise.

@rerrahkr
Copy link
Member

And releases page, to showcase the deployment here:
https://github.com/OPNA2608/BambooTracker/releases/tag/v0.4.2

the queued AppVeyor build.

I tested them on MacBook (macOS Mojave, 10.14.6) and they works well as far as I tested.

With MSVC now being a concern, I'll look into adding a build test for MSVC if this PR is still open when I have more time again.

MSVC is used for build testing, but not used for deploy. (Please let me know if your idea is different from this.) Since the deploy method is also changed in this PR, it may be better to work on another PR (or issue) if you implement only the test.

I've received your report and #223, that the build doesn't work well on old macOS. These reports are probably not a build method issue (maybe #223), so would you mind me merging this PR?

@OPNA2608
Copy link
Member Author

MSVC is used for build testing, but not used for deploy. (Please let me know if your idea is different from this.)

I gave expanding Travis CI with a MSVC build a shot afew days ago, didn't work out well. Requires setting up the VS stuff in the system shell with a Batch script, didn't manage to figure out anything that worked.

so would you mind me merging this PR?

Please do, I'll rebase it one more time to hopefully get CI all green and happy.

@OPNA2608
Rework CI
0391457 
· TravisCI GitHub Releases expanded
  (Windows {XP,7+}, macOS {Legacy,Modern})
· AppVeyor Debug Builds improved & expanded
  (Console on Windows, macOS build, debug symbols)
@OPNA2608
Copy link
Member Author

All green, feel free to merge. 👍

@rerrahkr rerrahkr merged commit 8a708ff into BambooTracker:master Jun 23, 2020
@rerrahkr
Copy link
Member

Thanks for your great contributions!

@rerrahkr
Copy link
Member

I happen to notice, the artifacts in the appveyor are bigger than those created with the previous settings. I recognize that this is because the build is created in debug mode by qmake BambooTracker.pro CONFIG+=debug CONFIG+=console CONFIG+=nostrip.
Just wondering, why did you change the option from CONFIG+=release CONFIG-=debug?

@OPNA2608
Copy link
Member Author

Development builds being compiled and optimised as releases doesn't sit well with me, I think it's better to build them with as much debugging information intact as possible.

I'm unsure what exactly the implications of debug without release are, but I'm assuming it has something to do with build optimizations. console should enable seeing stdout output on Windows (otherwise only works on Unixoids) which may help with bug reports, and nostrip leaves the binary with all of its symbol and debugging information intact, to help with independent debugging if anyone else is curious enough. The downsides of doing this are an increased binary size, possibly slower execution / disk access and much easier reverse-engineering, though that last point is really not a worry at all for us.

@rerrahkr
Copy link
Member

Well understand, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@OPNA2608 @rerrahkr