iTranslated by AI
2024 Year in Review: Engineering Activities
Seeing others I know writing their 2024 reflections, I realized it's already 2025, but I decided to look back on my own 2024 as well.
Reflection on last year (2023)
Speaking & Writing
While I didn't have the chance to submit any CfPs to conferences this year, in addition to giving three presentations at study groups, I had the opportunity to write a special feature on GitHub Actions for Software Design magazine as part of my company's productivity improvement team.
My presentations at TechBrew and CI/CD TestNight, as well as the contribution to Software Design, were related to GitHub Actions. At the Productivity Meetup in April, I presented on OSS release automation. Since both personally and as a team, we have been focusing heavily on GitHub Actions over the past few years, I'm glad I had the opportunity to share our work.
Generative AI
This year, the thing that influenced me the most was generative AI (especially in the LLM field). I had no interest in it at all until the era of GPT-3.5 Turbo last year, but with the release of GPT-4o, I realized it already possessed capabilities that could serve as an alternative to OCR, such as image recognition and JSON output, which sparked my interest.
I have a long-standing habit of checking github.blog/changelog every morning, and starting around this year, updates and feature explanation articles related to GitHub Copilot clearly increased. In the first half of 2024, since I wasn't interested in LLMs, I didn't understand terms like "RAG," and I felt that the number of uninteresting updates had increased because I couldn't follow the content.
Around the same time, discussions about LLMs also increased within the company, but again, I found myself unable to follow the conversation because I didn't understand the terminology. Since that wasn't any fun, I studied the inner workings of LLMs and peripheral technologies like RAG, which were popular at the time. This allowed me to understand GitHub Copilot-related updates, and I suddenly became very interested in LLMs themselves.
This is a scrap from when I was researching how to run LLMs on my own PC (local LLMs) and the VSCode extension called "Continue," which allows you to do things similar to GitHub Copilot using them. I thought about turning it into an article, but in the end, I was satisfied just keeping it as a scrap.
At Cybozu, where I work, there is a program called "Adult Experience Enrollment" (Otona no Taiken Nyubu) that allows for a short-term transfer to another team for up to three months. I took advantage of this and have been working since October in a team that focuses on LLM utilization within the company. So far, I'm not very interested in the inner workings of LLMs or model training; I'm more interested in tools that allow you to throw various tasks at LLMs like ChatGPT, or ways to integrate LLMs into existing services and apps.
Looking back, the reason I've been interested in CI/CD for the past few years was that I believed CI/CD could make software development more efficient. On the other hand, since GitHub Copilot pioneered LLM usage for coding, many engineers are already using it, and the work of non-engineering roles will also likely be significantly streamlined using LLMs in the future. Looking at software development as a whole, I believe it will contribute to efficiency much more significantly than CI/CD.
My colleagues were quite surprised by the shift in my interest from CI/CD to LLMs, but personally, I feel that the shift to LLMs was a consistent transition in terms of my interest in improving software development efficiency.
Another reason is that looking back at GitHub's updates as a whole in 2024, they were almost entirely focused on GitHub Copilot and security, and it felt like GitHub was no longer focusing on GitHub Actions, which was boring[1]. As a GitHub fanboy, even in terms of being interested in the features being prioritized, I think my stance hasn't actually changed much from before.
Donations
Continuing from last year, I have kept up my donations to OSS. For my stance on donations, please refer to last year's reflection article.
This year, I made some donations, primarily to individuals active in the JS/TS community and tools that I rely on. One new tool I started supporting is Biome. After the ESLint v9 turmoil, I tried out Biome and found it so convenient that it felt like "this is all I really need" for a linter and formatter.
OSS Activities
This year, my "grass" (contribution graph) turned out to be quite sparse. In the first half of the year through July, I was working on a new tool called gh-actions-scanner (mentioned below) in a private repository, so there was a decent amount of activity. However, from July onwards, I spent my time studying LLMs and trying out various tools instead of writing code. Plus, the Factorio DLC was released in October, and I've been playing it night after night, so the graph has become quite desolate.
(Participating in the viewer-inclusive multiplayer sessions with a Factorio streamer I watch on YouTube was simply too much fun.)
Since Copilot Workspace became available around October, I've been experimenting with how much LLMs can boost OSS development. Most "hands-on" articles for these kinds of tools only show examples of building TODO apps or landing pages from scratch (0 to 1). However, I've been keeping a scrap to record how well Copilot Workspace performs in a situation where a decent codebase already exists. I'd like to turn this into an article someday, but the LLM field evolves so rapidly that the situation might completely change in a few months, making it obsolete quickly.
Kesin11/gh-actions-scanner
This is a new tool I started making this year. I put a lot of effort into it during the first half of the year, but in the end, I couldn't finish it, and it's currently stalled in an incomplete state. What I wanted to create was something like a GitHub Actions performance version of trivy—a tool that finds optimization points from the perspective of GitHub Actions execution time by scanning.
Since I "know a little" about GitHub Actions, I sometimes help other teams at work improve their GitHub Actions. Through looking at various repositories, I've come to understand the key improvement points quite well. I could have summarized them in a document, but I started development thinking that turning them into a tool would allow for better scaling.
When there are performance issues with GitHub Actions, the first things to check are whether the cache has reached its 10GB limit or if an old version like actions/upload-artifact@v3[2] is being used, which takes a long time to upload if the artifact size is large.
gh-actions-scanner automatically detects these issues by cross-referencing data obtained from the API with the workflow YAML. These major issues are already detectable even now, and I've included sample execution results in the README.
So, it progressed beyond the POC level, but my motivation didn't last past six months, and development has completely stopped recently. The reason is that, for repositories within the company that use GitHub Actions heavily, most of the items detectable by gh-actions-scanner were already improved by talented colleagues during its development, so I lost the motivation to push it to completion. I also simply spent too much time on development.
On the bright side, I learned that by combining the analysis of GitHub Actions API results with the workflow YAML, it's possible to obtain information that cannot be determined by static analysis alone. I believe I can apply this know-how to actions-timeline, CIAnalyzer, and other projects in the future.
Kesin11/gha-utils
This is a package that separates the GitHub Actions API analysis and workflow YAML parsing logic, which were core components of gh-actions-scanner. I've essentially just split it into a separate package and haven't even written a README yet, but it is already published on jsr.io.
Since I find myself writing similar code for GitHub Actions API clients every time, I decided to consolidate it into gha-utils to share it between gh-actions-scanner and actions-timeline.
Kesin11/actions-timeline
Perhaps due to the effect of presenting it at TechBrew after its release last year, the GitHub Stars have thankfully continued to grow steadily.
It's being used in repositories that utilize GitHub Actions on a large scale within my company, and recently I've had more opportunities to be told "I'm using actions-timeline" at social gatherings after study groups. It has become a representative OSS project for me.
I haven't been able to do much development on it this year since adding the CLI that can be run locally in v2.1.0 released in February, but I am continuing maintenance like updating dependencies.
I couldn't spend much time on it this year because of gh-actions-scanner, but as I mentioned before, I'd like to leverage the know-how I gained there. Specifically, I've received feedback from teams using it internally that the fact that the breakdown within Composite Actions is not displayed is inconvenient, so I'm hoping to find a way to resolve this issue.
Kesin11/CIAnalyzer
CIAnalyzer is a project that predates actions-timeline. Since it requires the effort of setting up BigQuery at the very least, I thought not many people would be using it nowadays, but I was surprised to find that it's still being used in quite a few places.
Products like actions-timeline and CIAnalyzer are often used in private internal repositories rather than OSS, so I don't actually have a good grasp of how much they are truly being used. That's why I'm very happy when people write blog posts like this.
Like actions-timeline, maintenance was the main focus for CIAnalyzer this year, with internal updates such as migrating from CJS to ESM and introducing Biome. Seeing actual use cases has boosted my motivation a bit, so next year I'm thinking of working on S3 support as an experiment for AI-based coding tools.
In v6.2.0, I added support for GCS as an export destination for the first time (other than BigQuery), which was a perfect task to use as a test case for GitHub Copilot Workspace. Since CIAnalyzer already has a decent codebase and tests, it's ideal for seeing how useful modern AI coding tools are at the "1 -> 10" stage rather than "0 -> 1."
Others
This is a CLI tool that unfolds Reusable Workflows and Composite Actions within GitHub Actions workflow YAMLs to show exactly what steps will be executed, which can be difficult to track when they are heavily nested. I released this in 2024 as well.
I've only used it a bit myself when helping optimize GitHub Actions at work, but it's a bit of an interesting experiment in distributing an executable binary generated with deno compile as a gh extension. Usually, these kinds of tools use Go or Rust, which are common for creating easy-to-distribute binaries, but this was an example showing it's possible with Deno too (though the size ends up being around 80-90MB, so it's hard to say it has a major advantage).
ts-junit2json has a small codebase and is already quite complete, so I didn't add any new features this year. However, it served as a playground for adopting new ecosystem features, such as npm provenance support and publishing to jsr.io. I also updated it for Node.js v22 and removed Jest since node:test now supports snapshot testing.
As the number of things that can be done with just standard Node.js features increases, I can reduce dependency packages, and ts-junit2json is becoming slimmer year by year.
-
Specifically, I wonder when the new API for self-hosted runners used by actions-runner-controller will be released. I know from the ARC source code that it uses a preview version of the API. ↩︎
-
By the way, at the time of writing this article,
actions/upload-artifact@v3is deprecated, and there is an announcement that v3 will no longer be available on 2025/01/30. ↩︎
Discussion