Age | Commit message (Collapse) | Author |
|
Partial revert of D7520
|
|
This diff add supports for crash logs on windows for
release builds. This can be toggled on/off with the
`WITH_WINDOWS_PDB` cmake option. by default it is on.
Things to take into consideration:
Release builds are hightly optimized and the resulting
backtraces can be wrong/misleading, take the backtrace
as a general area where the problem resides rather than
an exact location.
By default we ship a minimized symbol file that can only
resolve the function names. This was chosen to strike
a balance between growth in size of the download vs
functionality gained. If more detailed information is
required such as source file + line number information
a full pdb can be shipped by setting `WITH_WINDOWS_STRIPPED_PDB`
to off.
The Release in the title of this diff refers to the
release build type, not the official blender releases.
Initially this will only be enabled for nightly build
bot versions of blender, official releases as of now
will not ship with symbols.
Differential Revision: https://developer.blender.org/D7520
Reviewed by: brecht
|
|
Differential Revision: https://developer.blender.org/D7309
|
|
Ref D7309
|
|
Allows to have 2.82a as a beta version on buildbot.
|
|
|
|
|
|
Seems like sometimes files are being only partially ready, which makes it so there
are unsigned files, failing to deliver fully signed bundle.
Now expected archive file size is stored into stamp file and is checked against
size of the archive file on another side.
There are some bare prints used for debugging, would need to switch it to a proper
logger (or to be removed).
|
|
|
|
Is still sometimes .ready file appears prior to an actual archive.
|
|
Apparently, there is no os.sync() on Windows.
|
|
From looking into builder's logs it seems that stamp file is picked
up prior to actual archive: sometimes worker reports missing archive
file, from a code path which is only possible if there is a stamp file.
Could be something with IO scheduling where bigger file is sent to
Samba server after smaller file.
Hopefully with this change this will not happen anymore.
|
|
|
|
Works similarly to Windows configuration where buildbot worker and
codesign machines are communicating with each other using network
drive.
|
|
|
|
It changes name to be blender-<version>-linux64.
Since CentOS is used as a base host for builds there is no real need
in specifying libc version. Is unlikely anything older could be used
anyway.
Also make bitness to be the same as windows. It is something what
users will read easier.
|
|
Makes it easier to verify changes on local machine without scl
before committing changes to repo.
|
|
|
|
|
|
The current authority we use RFC 3161 time stamp server,
so need to pass different command line argument.
|
|
xz compresses 25% better than bz2, reducing download times and server load.
The numbers:
blender-2.80-linux-glibc217-x86_64.tar.bz2 (release): 134 886 174 bytes
with xz: 96 181 604 bytes (-28.7%)
with xz -9: 93 871 548 bytes (-30.4%)
blender-2.81-7c1fbe24ca33-linux-glibc217-x86_64.tar.bz2 (beta): 173 600 363 bytes
with xz: 133 100 664 bytes (-23.3%)
with xz -9: 129 534 124 bytes (-25.4%)
xz also decompresses more than twice as fast as bz2, however compression needs
four times as long (on my 7-year-old laptop 3-4 minutes instead of <1).
Also xz has become more common than bz2, e.g. Debian/Ubuntu deb packages have
been xz-compressed for years, so the dpkg package manager as well as systemd
and grub all depend on liblzma being present, whereas bz2 is becoming more and
more optional.
Current Linux archives also include the UID/GID of whatever user account
happens to be used for building by the blender.org infrastructure. If someone
then installs these archives as root e.g. to /usr/local/... and doesn't pay
full attention the files remain owned by a regular user, which is a serious
security issue. This patch fixes that by setting the UID/GID to 0.
Differential Revision: https://developer.blender.org/D6138
|
|
It was possible that it would exceed when signing all the DLLs if the machine
is busy with some background tasks or when internet is slow.
|
|
The script requires Python 3.7 as a very minimum, and CentOS is
only 3.6.
On macOC there was an access to a None object, due to missing
implementation of code signer on this platform.
|
|
This changes integrates code signing steps into a buildbot worker
process.
The configuration requires having a separate machine running with
a shared folder access between the signing machine and worker machine.
Actual signing is happening as a "POST-INSTALL" script run by CMake,
which allows to sign any binary which ends up in the final bundle.
Additionally, such way allows to avoid signing binaries in the build
folder (if we were signing as a built process, which iwas another
alternative).
Such complexity is needed on platforms which are using CPack to
generate final bundle: CPack runs INSTALL target into its own location,
so it is useless to run signing on a folder which is considered INSTALL
by the buildbot worker.
There is a signing script which can be used as a standalone tool,
making it possible to hook up signing for macOS's bundler.
There is a dummy Linux signer implementation, which can be activated
by returning True from mock_codesign in linux_code_signer.py.
Main purpose of this signer is to give an ability to develop the
scripts on Linux environment, without going to Windows VM.
The code is based on D6036 from Nathan Letwory.
Differential Revision: https://developer.blender.org/D6216
|
|
This wasn't an issue in the real buildbot environment since the
precompiled libraries are compiled with same ABI as the compiler
used for Blender build. But it was causing issues when building
Blender using buildbot scripts (for troubleshooting purposes)
on a machine with different default compiler ABI.
Usually ABI detection is happening in platform_unix.cmake when
detecting whether there are any precompiled libraries folder
available. This detection is not happening when library folder
is provided explicitly, expecting ABI to be setup explicitly
as well.
|
|
|
|
Removes custom logic from buildbot's packing step.
This also removes icons/ folder, but CMake was already copying the
icons to the root of the install folder.
|
|
Off-by-one calculating parent folders.
|
|
The CMAKE_SOURCES variable is not yet initialized when the buildbot
configuration is read. This is similar to the include of full release
configuration happening earlier in the file.
|
|
|
|
|
|
This uses hardware-accelerated raytracing on NVIDIA RTX graphics cards.
It is still currently experimental. Most features are supported, but a few
are still missing like baking, branched path tracing and using CPU memory.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Cycles#NVIDIA_RTX
For building with Optix support, the Optix SDK must be installed. See here for
build instructions:
https://wiki.blender.org/wiki/Building_Blender/CUDA
Differential Revision: https://developer.blender.org/D5363
|
|
|
|
Blender can only be run correctly from the install path since it requires Python
scripts, dynamic libraries and other files to be present. By default the install
path is the same as the build path, so it works anyway. But on the buildbot it
isn't. There was a workaround but it failed on Windows and macOS.
Now tests run from the install path. Detecting that path for ctest is more
complicated than I would like, but I couldn't find a better solution.
Ref T69541.
|
|
|
|
These will not stop the build on failure yet, first step is to get them passing
more reliably.
|
|
|
|
|
|
* Auto detect rc and release version cycle in BKE_blender_version.h.
* On Windows, generate zip and installer if a release is detected.
* On macOS, always generate a dmg instead of zip.
* Use standard package names without hash if a release is detected.
* Buildbot package names now match platform names in releases.
Ref T67056
Differential Revision: https://developer.blender.org/D5643
|
|
* Move common code into buildbot_utils.py
* Remove legacy code from removed builders
* Split code into smaller functions
Differential Revision: https://developer.blender.org/D5642
|
|
This is meant to replace the individual build steps for the various libraries
and submodules, so we can easily get the correct revisions associated with
different branches and releases.
|
|
T68035 by @luzpaz
|
|
It causes some false indication of a failed build on soma platforms
where it times out.
Windows and macOS needs extra work to properly support python paths
and path to the bundle.
This can now happen without poking git every time by doing local
modifications on a builder prior to commit.
|
|
|
|
|
|
|
|
The `scripts` is to be included into the path, not just the
folder where the scripts are.
Also specify path to datafiles.
|
|
|
|
|
|
|