This is one of the big problems we solved with the RWX CI platform (RWX.com). You can use ‘rwx run’ and it automatically syncs your local changes, so no need to push — and with our automated caching, steps like setting up the environment cache hit so you don’t have to execute the same stuff over and over again while writing your workflow. Plus with our API or MCP server you can get the results directly in your terminal so no need to open the UI at all unless you want to do some in-depth spelunking.
It's really concerning that the biggest, most eye-grabbing part of this posting is the note with the following: "It’s common for critical CVEs to uncover follow‑up vulnerabilities."
Trying to justify the CVE before fully explaining the scope of the CVE, who is affected, or how to mitigate it -- yikes.
What’s concerning about it? The first thing I thought when I read the headline was “wow, another react CVE?” It’s not a justification, it’s an explanation to the most obvious immediate question.
It's definitely a defensive statement, proactively covering the situation as "normal". Normal it may be, but emphasizing that in the limited space of a tweet thread definitely indicates where their mind is on this, I'd think.
fwiw, the goal here wasn't to downplay the severity, but to explain the context to an audience who might not be familiar with CVEs and what's considered normal. I moved the note down so the more important information like severity, impacted versions, and upgrade instructions are first.
If there are so many React developers out there using server side components while not familiar with the concept of CVEs, we’re in very serious trouble.
It's ok, you gotta play the game. I'm more concerned about the fact that the downtime issue ranks higher than the security issue. But I'm assuming it relates to the specifics of the issue rather than reflecting on the priorities of the project as a whole.
I had the same experience -- it was way easier for me to find it with the rainbow highlighting (even though I already knew where to look when it came to the monochrome highlighting!).
The author later asks what color class definitions were. I think this fundamentally gets wrong how syntax highlighting helps humans. I don't have a clue what color anything is in my favored highlighting, but my brain does incredible pattern recognition to help me digest code in it without me consciously knowing what color does what.
So his arguments for why there's a problem don't hold up, but that doesn't mean there is not in fact a problem.
Yeah I certainly dont' pay attention to or remember what color means what.
I am however in that weird minority that prefers light themes, and I do also prefer minimal syntax highlighting. The author does have a point to an extent, but I don't think there's any one objectively better way to do it I think it's all personal preference.
I don't like the rainbow highlighting, too distracting for me, and doesn't work particularly well with light themes. I did try the author's alabaster theme in VSCode though and it highlights the wrong things for me.
(In C#) if I have var result = await SomeMethodName(param, param, param); It put both "result" and "SomeMethodName" in blue, the rest being black. I'd actually prefer it the other way around, highlight the programming language's keywords (var and await in this case) and leave my own names (result and SomeMethodName) unhighlighted.
The theme was also inconsistent. The post says we shouldn't highlight PL keywords, but the proposed theme does highlight some keywords while ignoring others.
We use a somewhat similar approach in RWX when pulling LFS files[1]. We run `git lfs ls-files` to get a list of the lfs files, then pass that list into a task which pulls each file from the LFS endpoint using curl. Since in RWX the output of tasks are cached as long as their inputs don't change, the LFS files just stay in the RWX cache and are pulled from there on future clones in CI. In addition to saving on GitHub's LFS bandwidth costs, the RWX cache is also _much_ faster to restore from than `git lfs pull`.
Nice! I was considering using some sort of pull through cache like this, but went with the solution that didn’t require setting up more infra than a bucket.
Not on iOS, as I understand it. If you "Ask app not to track" on iOS then the app cannot access your IDFA, which was the ID that previously was used to track a device across apps.
Come check out RWX :). We have per second billing but I think it won't even matter for your use case because most of those checks are going to take 0s on RWX. And our UI is optimized for showing you what is wrong at a glance without having to look at logs at all.
* Your per min billing is double blacksmith's
* RWX is a proprietary format? vs blacksmith's one line change.
* No fallback option, blacksmith goes down and I can revert back to GitHub temporarily.
It's pretty amazing to see what Blacksmith, Depot, Actuated, etc. have been able to build on top of GitHub Actions. At RWX we got a bit tired of constantly trying to work around the limitations of the platform with self-hosted runners, so we just built an entirely new CI platform on a brand new execution model with support for things like lightning-fast caching out of the box. Plus, there are some fundamental limitations that are impossible to work around, like the retry behavior [0]. Still, I have a huge appreciation for the patience of the Blacksmith team to actually dig in and improve what they can with GHA.
In my experience (and as reflected by the comments on this post already), trying to run complex CI workflow locally is a fairly hopeless enterprise. If you have a fully containerized workflow, you might be able to get close, but even then ensuring you have all of your CI specific environment variables is often not a trivial task, and if your workflow orchestrates things across tasks (e.g. one task uploads an artifact and another task uses that artifact) you'll have a hard time reproducing exactly what is happening in CI. My company (RWX) builds a GitHub Actions competitor and we intentionally do not support local execution -- instead we focused on making it easy to kick off remote builds from your local machine without having to do a `git push` and we made it easy to grab an SSH session before, during, or after a running task to inspect things in the exact build environment that your workflow is running.
> The orange remains in the living room. Moving the plate to the kitchen does not affect the location of the orange, since it was placed below the plate but not attached to it. Therefore, the orange stays where it was originally placed, which is in the living room.
You don't need to visualize it in your mind to understand the relationship between being _below_ and being _moved with_. Keep in mind that many people cannot visualize anything in their mind!
I have wondered how do people blind from birth create their mental world? Is it all dark with no color or light and only sound? No shapes? Or do they still form mental images from non visual sensory inputs?
reply