There were complaints about no patch files being created from CI when
the examples pre-gen fails for people who don't build with bazel. This
adds a new action step to run just the non-robotpy pregen.
I also added an argument to the diff tests to make it a unified diff,
which might make it easier to hand fix.
Commands v3 had a few changes due to the upgrade:
- Java 24 removed the Pinned: MONITOR IllegalStateException when
yielding in a synchronized block, so we no longer need to special case
for it
- Lambda method name generation was tweaked, requiring tests to be
updated
- Bazel java_rules needed to be bumped to support Java 25
Closes#8425
When downloading a patch to fix linting errors, it's annoying to have to
unzip it, particularly when it's a single file. This PR updates the
`upload-artifact` action to v7, which allows for uploading an artifact
without zipping it. It also sets archive to false for all patches
generated by linting.
Each Bazel Windows CI job is currently redundantly evaluating the build
actions for both the `opt` and `dbg` compilation modes.
If we group the debug artifact builds together (instead of grouping by
the shared/static library artifacts), the `dbg` compilation mode actions
no longer need to be executed across multiple CI jobs in the matrix.
(Yes, the CI jobs are sharing the Bazel cache, but there's still
overhead in checking the action cache for each action. It's also
possible that two jobs will race to execute the same action.)
| Total actions per job | [Before] | After |
|----------------------------|---------:|------:|
| Windows x86-64 | 12277 | 10179 |
| Windows x86-64 Static | 11947 | n/a |
| Windows x86-64 Debug | n/a | 9895 |
| Windows ARM64 | 5518 | 3420 |
| Windows ARM64 Static | 5304 | n/a |
| Windows ARM64 Debug | n/a | 3272 |
| Windows System Core | 4836 | 2916 |
| Windows System Core Static | 4576 | n/a |
| Windows System Core Debug | n/a | 2916 |
[Before]:
https://github.com/wpilibsuite/allwpilib/actions/runs/23781230818
This should hopefully translate to shorter wall-clock time Windows CI
jobs.
In https://github.com/wpilibsuite/allwpilib/issues/8681 we discovered
that multicast service types need to be valid (end with _tcp or _udp),
or else errors are silently swallowed. Let's make our C++ unit test use
a valid name and also check that it works. I think if we
should/shouldn't do this is up for debate still.
I also discovered two bugs in the JNI code that lead to incorrect
results being returned
- Return array index was always 0
- Use of JLocal for the return value seems to mean that the array will
always be NULL in java
I ran the following locally:
```bash
gradle generateCompileCommands
./.github/workflows/fix_compile_commands.py build/TargetedCompileCommands/linuxx86-64release/compile_commands.json
wpiformat -default-branch 2027 -no-format -tidy-all -compile-commands=build/TargetedCompileCommands/linuxx86-64release
```
The `HeaderFilterRegex` option is used to filter out warnings from
thirdparty headers.
This changes the HAL notifier interface to:
- Use wpiutil signal objects. This means waiting is done through the
`WPI_WaitObject` API instead of a dedicated function and allows for
higher level code to simultaneously wait on notifiers and other events.
- Interval timers are supported at the HAL layer
- Handlers are now required to acknowledge notifications. This is
invisible to users unless they're directly using the HAL API.
- For interval timers, an overrun count is maintained to detect if the
handler didn't acknowledge
The underlying implementation still uses condition variables for the
actual waiting. In basic testing using this approach seemed to be lower
jitter than timerfd.
Currently, the simulation and systemcore implementations are nearly
identical except for a few additional sim hook bits. This could be
refactored, but keeping them separate may make sense to keep the
systemcore implementation easy to read and reason about, or if we ever
choose to use a different underlying timer implementation on systemcore.
The simulation side API is unchanged in form but does change in
function--waiting for notifiers now only waits for currently running (or
newly signaled) notifiers to acknowledge. To avoid a race condition in
sim stepTiming, users of the low level API must make any alarm updates
(especially for one-shot alarms) prior to acknowledging the previous
alarm.
The only current use of the interval timer feature is the `Notifier`
class. The `TimedRobot` implementation still uses a single notifier and
its own interval timing logic to ensure consistent callback order. Using
separate notifiers for each user-level interval would substantially
increase complexity. `Watchdog` also doesn't use the interval timer, as
it's looking for an amount of time since the last `set` call rather than
a recurring interval time.
To reduce flicker, the sim GUI uses a fade out when a timeout goes from
set to unset.
This fixes tsan for wpilib and commands, and also fixes some spurious
test failures.
#8363 split all the cross-compilation into separate jobs, however these
jobs are still also building the world (including the tests) targeting
the host.
Since `//:publish` and its dependencies are transitioned to target the
desired platforms for each artifact, `bazel build //:publish` in the CI
jobs that aren't running tests to only build what we actually care about
in these jobs.
This saves around 1 to 1.5 minutes for each cross-compile job with 100%
cache hit rates.
I'm not entirely sure why Java header compilation is disabled for the
macOS build. But this option will be causing rebuilds to happen more
often than strictly necessary.
[Turbine](https://github.com/google/turbine) takes Java class sources
and spits out .class files with all method bodies, and private fields
and methods stripped. This provides a .jar with sufficient information
on the classpath to build dependent Java libraries without depending on
the implementation in the build graph.
The update yaml step _might_ cause changes that would affect the build
file generation. Since `bazel run //:write_robotpy_update_yaml_files`
runs them all at once, user that was using the github action to fix
their python stuff would end up having to run it twice.
By running the steps individually in series, this should be able to get
it in one swoop.
We are running out of disk space. If we split the
build up more in parallel, that'll use less space in each build.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Offline conversations have pointed out that the bazel output is very noisy upon a failure. The -k that was there for a while was recently deleted in another PR, and this one removes --verbose_failures. --verbose_failures prints all of the command line arguments, which can be quite lengthy and make it harder to find the actual compiler error.
This also removes the -vv from the clang-tidy step. I have found it very hard to find the actual errors when its printing out all of the debug information.
This uses all the infrastructure we put together earlier to actually build and publish all the artifacts.
We might still want to adjust what is built by default to control CI times.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
This is owned by WPI, so we can make it as big or small as we want.
This lets us check in more of the bazel build.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
clang-format 21 made some formatting changes. Since wpiformat's stdlib
task was removed, I removed NOLINT comments for it and removed some
std:: prefixes it added to comments.
We build docs in three different places, which is annoying to deal with, and it means we build docs two more times than necessary. Now, docs are built just once in the main Gradle workflow, with warnings promoted to errors, eliminating the need for the separate job in lint-format.yml. The uploaded docs artifact is then unpacked and commited to the GitHub Pages repo like normal.
