## About the changes
We've been using vitest for coverage and we use a github action to push
results to coveralls, so this should work just fine
Unlocks form-data to be able to fix
https://github.com/Unleash/unleash/security/dependabot/267
Also, removing coverage from PRs to avoid running tests twice
The console was complaining. I suspect it was because of the wrapping
fragment. So instead of doing everything within react, I switched to
using a standard case statement.
Also: because name is optional and not guaranteed to be unique, let's
use id for the key instead.
When deleting stale sessions, we sort them by createdAt. If both
sessions are created with the same createdAt, there's a chance we get a
different sort order and we end up with the wrong order:
https://github.com/Unleash/unleash/actions/runs/16438565746/job/46453700977
I think adding 10ms between inserts should be enough (1ms should do,
but this gives me more confidence and doesn't hurt that much)
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
https://linear.app/unleash/issue/2-3696/report-unknown-flags-when-sent-to-the-bulk-metrics-endpoint
Unifies metrics sifting logic across both metrics endpoints:
- `/metrics`
- `/metrics/bulk`
This PR improves consistency between the `/metrics` and `/metrics/bulk`
endpoints by introducing a shared `siftMetrics` method, now used within
`registerBulkMetrics`. Both endpoints already call this method at the
end of their respective logic flows, ensuring that metrics are sifted in
the same way regardless of the path taken.
While the primary goal was to enable reporting of unknown flags via the
`/metrics/bulk` endpoint, this change also improves bulk processing by
consistently dropping invalid or unknown flags before insertion, just
like in the regular `/metrics` endpoint.
## About the changes
Currently, if a PR is open and a push happens, the **e2e:frontend**
workflow will start running. If, shortly after a subsequent push on the
*same* PR happens, the workflow will start running again without
cancelling the previous (now obsolete) run. With these changes, the
first run would be cancelled, thus **saving compute resources** (see
below for quantity) that can be used to **speed up your overall CI/CD**,
without sacrificing functionality, since the second run will contain the
changes from the first push as well. 🌱
### Example
Here is an example of the behaviour described above: the commit
`b1b2e61` triggered
[this](https://github.com/Unleash/unleash/actions/runs/14493085673/)
workflow run, and shortly after the commit `9997fe1`, that happened on
top of the first commit, triggered
[this](https://github.com/Unleash/unleash/actions/runs/14493089012/)
workflow. Both workflows ran till the end, spending approximately 8 CPU
minutes each. With the proposed changes, the first run would be
cancelled, hence saving ~8 CPU minutes and clearing the queue for other
workflows. Note that this is an example of a single concurrent run; the
accumulated gain for all PRs would be higher, with a lower estimate at
**2 CPU hours** over the last few months.
The same holds for these workflow(s) as well: Dependency review, PR ->
Build Docs.
### Context
Hi,
We are a team of [researchers](https://www.ifi.uzh.ch/en/zest.html) from
University of Zurich and we are currently working on energy
optimizations in GitHub Actions workflows.
Kindly let us know (here or in the email below) if you would like more
details, if you want to reject the proposed changes for other reasons,
or if you have any question whatsoever.
Best regards,
[Konstantinos
Kitsios](https://www.ifi.uzh.ch/en/zest/team/konstantinos_kitsios.html)
konstantinos.kitsios@uzh.ch
