On 5. 6. 25 23:02, Branko Čibej wrote:
On 5. 6. 25 22:27, Daniel Sahlberg wrote:
Den sön 1 juni 2025 kl 19:39 skrev Nathan Hartman
<hartman.nat...@gmail.com
:
On Sun, Jun 1, 2025 at 11:39 AM Daniel Sahlberg <
daniel.l.sahlb...@gmail.com> wrote:
Den sön 1 juni 2025 kl 16:31 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
Hi,
I like the e-mail notifications from GitHub Actions when a build
fails
or
when it starts to work again - saves some time from going into the
website
to check status.
Should we enable this for Serf?
Should it go to dev@ or should we create a separate notifications@
list?
I presume the safe path would be to just create a separate mailing
list
and add notifications there, but maybe there is not really need for a
separate list?
Oh, there IS a notifications@ list already, see
https://lists.apache.org/list?notificati...@serf.apache.org. It was
last
used in 2020 by BuildBot (I assume it was never migrated to the new
ci2.apache.org, can't find Serf there). The list has TWO subscribers
(actually: three, since I just joined) so I assume there is little
harm in
setting up notifications to that list.
I'm going to assume lazy consensus to do this, if no replies within
the
next 72 hours (although it may take longer than that).
+1 for this, similarly to how we've done for Subversion. Since most/all
(?) of the Serf devs are also Subversion devs, there's an advantage in
being consistent!
I went ahead with this.First notification was received earlier
tonight [1].
For the record, this is controlled by the ghactions.py script in ASF
Infra's git repo infrastructure-gha-notifier[2]. I made a pull request
which was kindly merged by Humbedooh [3].
Feel free to subscribe tonotificati...@serf.apache.org if you want to
receive those notifications.
Regarding the current state of GitHub actions:
* Windows x86 (32-bit) CMake builds are failing and I have absolutely
no idea why. The last output is during the build, says "Generating
code...", then exits. No diagnostics, nothing.
The Windows builds are working now. Setting the target platform, as Tima
suggested, does work, for both x64 and x86 builds.
One more thing we can do is to reduce the size of the Windows matrix
from 4 to 2: as things stand now, a single CMake configuration can
produce both debug and release builds on Windows. We could reduce the
time spent on building dependencies by combining debug and release.
Or we could enable binary caching again, bit that involves messing with
NuGet and setting up our own cache (on GitHub), and I'm not going to do
that; I've other things on my plate.
-- Brane
