-
Notifications
You must be signed in to change notification settings - Fork 614
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
Master issue for remaining CI hiccups #364
Comments
One other thing I forgot we need to look into: testing build reproducibility via CI. This part won't block unless it's super trivial. |
And another TODO for myself: add info about file sizes for the artifacts; may be relevant to the first question in this issue And one more: see if we really need (Also AppVeyor is very slow but apparently I need to pay if I want even two simultaneous builds in a single commit :| Unless I am wrong, or I need to make the individual builds parallel a la |
OH YEAH WHILE I AM REMEMBERING STUFF the Travis file used to have specific |
It's possible, if we remove But maybe better way is just remove |
Fine for now, I guess (#358 (comment)):
|
For
It's still there: (or I misunderstood something) Line 1 in 9d74f9f
|
Strange, but
But this one works - Another option for AppVeyor speedup is Rolling builds - if this mode enabled, each new |
Oh really useful options! |
@mischnic I meant language settings that specifically named Objective-C and probably also C++ I forget |
In re AppVeyor msbuild with 2 jobs being slower than with 1:
This indicates that running with 2 or even 3 concurrent processes in I may also consider turning on Build Cache, if that's even available to a free account. (If only non-Enterprise paid accounts weren't limited to two (2) concurrent builds...) |
I don't think neither travis nor appveyor does reserve CPU time for each running instance (at least not in the free version) so maybe their system is under more heavy load when @msink did his tests with the flags? |
@mischnic, @msink so I figured it out: the I'm still running a |
I'm not sure it worth troubles... |
@andlabs You also can ask appveyor support (by email) what can be done. |
Does the AppVeyor environment include any of the following?
|
|
If you want to experiment, better connect via Remote Desktop |
Here is a list (might not be complete): https://www.appveyor.com/docs/build-environment/ |
All right. Not sure if jom comes with Qt, so I'll try the curl option instead, or building GNU make from source outside of mingw or msys. |
AFAIK pure GNU make cannot work on Windows, outside of cygwin or msys2. |
Yes it can. Download the source code, enter a MSVC shell, and run the included Anyway this experiment didn't work because trying to shove all this configuration into YAML is a recipe for disaster; it includes various cmd.exe complexities that I'd rather just split into separate .bat files before trying again (unless there's a magic yaml mode that lets me forego indentation for a single entry in a list, or use tabs for indentation instead of spaces, and at least ensures each entry in the yaml file is run in the same cmd.exe instance). We'll see what I decide tonight. |
Again, is it worth troubles? :) Anyway, nowadays fastest and cross-platform build tool is not make but ninja. |
So I don't forget:
|
data point: NoraCodes/libui-rs@859e178 |
I ship the binaries with LibUISharp. I'm not sure what the reasoning is (and I'm pretty late to the party), but I think it would be helpful to have artifacts on commits that aren't tagged as well. Possibly a version like |
The problem with that is that I normally make frequent tiny commits, so per-commit isn't going to work nicely. Some other granularity would be needed for that... and where would the artifacts go? |
I know appveyor will hold them with each of the build results, and store them there (with some settings in the yml file), but I don't know about travis. And travis will do daily builds (or weekly), also. You could probably set appveyor to do that as well, I don't know about that either, though. |
On the topic of artifacts and appveyor, heres the artifacts from the latest build: https://ci.appveyor.com/project/andlabs/libui/build/job/x35tskq2v0kewnqn/artifacts |
For travis, I can only see adding releases to github by adding a |
And AppVeyor will soon be trashing old artifacts as well... |
Well isn't that just nice? I guess the only way would be daily builds or weekly builds with some sort of prerelease tag (i.e |
New plan: since I'm going to release Alpha 4 as libui stands now, we'll test that the CI works using it. If any of the files are bad, I'll use a manually-created upload for that file instead, and we'll mark that one as needs attention here. AppVeyor being slow can be dealt with later. |
Sounds good. Once this is done, I'll have my own CI set up to make and distribute libui libraries with LibUISharp. |
One more TODO: make sure binary distributions in Azure Pipelines works. I'll need to turn the above list of TODOs into a proper check list. |
I still prefer a single combined archive containing both libui itself and examples, but that apparently will cause problems for libui-node, which needs to download archives (instead of shipping the binaries with the source code). What do other bindings do?
Is it possible to say "don't generate artifacts under condition X Y Z"? Because I don't need all build configurations in the CI to produce artifacts, only specific ones.
Are we sure
${version}
will be the tag name, and notmaster
or1.0.whatever
in the case of AppVeyor? I still need to figure out what1.0.whatever
should really be...I'll also need to include the LICENSE with the artifacts.
The remaining TODOs in both YAML files are also to be solved.
The text was updated successfully, but these errors were encountered: