Automating binary attachments to release. #157
Conversation
.travis.yml
Outdated
| - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew update; fi | ||
| - if [ "$TRAVIS_OS_NAME" == "osx" ]; then brew upgrade cmake; fi | ||
| - mkdir build | ||
| - mkdir artifacts |
There was a problem hiding this comment.
Here I made an artifacts dir to keep all zip files before deploying them
.travis.yml
Outdated
| - if [ "$TRAVIS_OS_NAME" == "osx" ]; then LIB_FILE=libui.A.dylib; fi | ||
| - cd out | ||
| - tar -cvf ../../artifacts/examples-shared-$TRAVIS_OS_NAME-$TRAVIS_TAG.tar.gz controlgallery controlgallery histogram $LIB_FILE | ||
| - tar -cvf ../../artifacts/libui-shared-$TRAVIS_OS_NAME-$TRAVIS_TAG.tar.gz $LIB_FILE |
There was a problem hiding this comment.
I'd actually rather have everything for an OS and build type in one archive, rather than a separate one for examples, especially since you're including the library in the examples archive anyway
There was a problem hiding this comment.
I made a separate archive only for lib because I don't want to increase file size I'll have to download, but I noticed they are really small ones, so ok. Maybe I put them in a examples folder?
|
What is appveyor? |
|
AppVeyor it's a CI environment similar to travis but running on windows. IT already support |
|
Cool, that sounds great. I'll probably not do this right away, but rather closer to the Alpha 4 release, since I still have one more thing I promised I'd have in Alpha 4 to implement (table views). Thanks for all your effort in the meantime; it's much appreciated! |
|
Also: The thing with a separate examples directory is that the executables are programmed to look for the libui shared object first in the same directory as the executable, and then in system directories. On second thought, if it makes distribution easier for other languages, then a library-only archive would work. I'd call the two archives something different to flag them to people looking at the GitHub website. |
|
I'll continue to improve the PR, in the meanwhile I'll use my fork releases as a test repo for my |
|
What did you have in mind? |
|
@andlabs changed it from a class to a struct here. @mischnic is correct, @parro-it We desperately need AppVeyor CI on the main build to catch these sorts of problems! |
|
Trying that fix: https://ci.appveyor.com/project/parro-it/libui/build/1.0.180 |
|
It compile indeed!
As it works now, artifacts are only published when new tags are pushed, not for normal commits. Anyway, I'm fine about splitting this PR if that could help. |
|
I created a PR for the fix #340 |
|
Oops. Can't fix it until I leave work though. (FWIW I changed it to a struct because I felt like making it a class was a bit overkill (and I'm not much of a fan of operator overloading but eh). I don't oppose using classes in libui though (I use them for COM objects, after all =P ).) |
|
And yes, as for |
Take your time, I stop working on this now anyway, tomorrow I'll get married, I should prepare 🎉🎉🎉 |
|
Congratulations! |
Thank you! |
|
Congratulations! |
|
@parro-it Congratulazioni amico mio! |
|
😢 Grazie mille! |
|
Ma certo! |
|
Spagnolo e un po 'di portoghese. Sono simili. ;-) |
yo también un poco 😀 |
|
Is this PR still relevant? I thought I merged it already... |
|
Oh, I thought you already closed it. |
|
Happy new year!!🎉🎉 |
|
👍 |
Hi, I'm trying to automate the process of binaries attachment to GH releases.
We previously discussed this stuff on #124.
I will use these binaries on libui-download to avoid compile libui on each libui-node install.
This is a work in progress. Just publish the PR to get early feedback from you...
Some open issues and questions: