No Nightly builds from July 25th #957
-
Hello! @dmex did you disable CI for your repo? If you did, why? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
No? Nothing has changed. It might be confusing when compared to other projects but I've always triggered the CI build manually and it has never been automatic. I configured it this way to prevent github and/or CI itself from being an attack vector and to guarantee higher quality nightly build releases. So your question should be why haven't I triggered the CI for the nightly builds? Two big changes required more thorough testing than usual.
"Reboot to firmware options" These three menus let you reboot directly from the desktop into the BIOS setup screen or reboot directly into EFI applications (e.g EFIShell and Memory Diagnostics) and/or EFI devices (DVD/Ethernet/USB devices) and separate operating systems (even directly into a VHD file if you've configured one). Process Hacker is the first application to use the undocumented BCD functions to a large extent and the first application to include boot loader reboot functionality such as this feature. I want to be absolutely sure it doesn't cause any unintended side effects or other issues like failed startups or boot loops... To that end, we're using the 'one-time' feature provided by BCD for these restarts, so failed configurations are guaranteed to be automatically recovered. That feature needs to work, so I've been running tests and asking a few people for code reviews before releasing the feature to everyone on the nightly branch. TLDR: I want the reboot feature fully-baked rather than half-baked.
You can see the new (inline function) entries on the thread stack as well as stack source line information. This completely changed how PH enumerated thread stacks as well as changed code required for MiniDumpWriteDump which is used for both the Process > Create dump feature but also our own exception handling dialog. For example: I don't want to be in the position where the new boot configuration data functionality causes a crash but we don't ever know about it because our new stack support doesn't capture the crash information or somehow broke the exception handling. TLDR: Brand new reboot feature + brand new exception/stalk walking/minidump support = accident waiting to happen.
Yep. I've been committing other changes as well but there were also some commits fixing and improving both of those features. So it was a good idea to pause nightly releases and let them 'bake' a bit longer so I can guarantee they're working properly. Everything is looking good so I'll be releasing both the new reboot to device/reboot to firmware feature and the new dump support/inline stack features in the next few days and resuming the nightly builds 👍 |
Beta Was this translation helpful? Give feedback.
No? Nothing has changed. It might be confusing when compared to other projects but I've always triggered the CI build manually and it has never been automatic. I configured it this way to prevent github and/or CI itself from being an attack vector and to guarantee higher quality nightly build releases.
So your question should be why haven't I triggered the CI for the nightly builds? Two big changes required more thorough testing than usual.
"Reboot to firmwar…