iTranslated by AI
Productivity Weekly (2021-02-24 Edition)
Hello. I'm Hiraki-ba from the Productivity Improvement Team at Cybozu, Inc.
Our Productivity Improvement Team holds a weekly internal meeting every Wednesday called "Productivity Weekly," where we share tips and news discovered during the week related to improving developer productivity.
This article is a compilation of the topics from that session.
This is the 15th edition. You can find past articles here.
news
GitHub CLI now supports editing issues and pull requests, and pull request auto-merge - GitHub Changelog
GitHub CLI (the gh command) now supports auto-merge, which recently became GA.
You can enable auto-merge for a pull request by running gh pr merge --auto.
The auto-merge feature itself was already a great help, but now that we can enable it without opening a browser, it has become even more convenient.
GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions - GitHub Changelog
Starting from 2021/03/01, GitHub Actions workflows triggered by Dependabot pull requests will be treated similarly to workflows executed from a fork.
Being treated as a pull request from a fork results in the following changes:
- Previously, write permissions were available, but from now on, a
GITHUB_TOKENwith only read-only permissions will be used (Reference) - Previously, all secrets were passed to the workflow, but from now on, no secrets other than
GITHUB_TOKENwill be passed (Reference)
With this change, even if a malicious change is included in a dependency, it eliminates the possibility of the GITHUB_TOKEN being abused or secrets being captured at the Dependabot pull request stage.[1]
Since this change currently applies only to Dependabot, similar risks remain for those using third-party dependency update tools like Renovate. It would be nice to have an option to treat pull requests created by GitHub Apps as if they were from a fork.
Japanese Translation of "ISTQB Advanced Level Specialist Syllabus: Test Automation Engineer" Released
The Japanese translation of the "ISTQB Advanced Level Specialist Syllabus: Test Automation Engineer" has been released.
Other syllabi provide a compact summary of what you should know about software testing. The Test Automation Engineer syllabus also seems to compactly cover matters related to test automation.
However, since it is labeled "Version 2016.J01," the content might be a bit dated. Those involved in software testing or studying test automation may find it useful to look through[2].
know-how
InnerSource: Implementing Open Source Best Practices Within a Company / How to implement InnerSource - Speaker Deck
This slide deck by Microsoft/GitHub summarizes the know-how for deploying OSS ecosystems and best practices within a company.
It covers descriptions of InnerSource (so-called internal OSS), how Microsoft changed its internal structure to achieve InnerSource, and how they utilized GitHub to realize InnerSource.
Even when you try to create internal OSS, you may encounter obstacles—from an administrator's perspective, it's hard to find contributors, or from a contributor's perspective, it's hard to even know where the internal OSS is located. For those who want to realize InnerSource, the know-how in these slides will be very useful.
I tried writing ARCHITECTURE.md - maru source
This article describes what the developer of Jasper paid attention to and their impressions when writing an ARCHITECTURE.md.
ARCHITECTURE.md summarizes the entire system with simple diagrams and text. Perhaps because it is a relatively recent concept, the links in the article were all new. This article keeps the explanation of ARCHITECTURE.md itself to a minimum, focusing instead on the points of caution and impressions from writing it.
The purpose of ARCHITECTURE.md itself is something like "enabling new project participants to efficiently grasp the overall picture."
As mentioned, ARCHITECTURE.md is positioned as material for people considering contributing. I thought the existence of such documentation would be helpful when wanting to realize the previously mentioned InnerSource as well.
This article can serve as a reference for writing an ARCHITECTURE.md, so it is recommended not only for OSS developers but also for those wanting to implement InnerSource.
I wrote about the trouble I had when an AZ failure occurred in AWS - Nanka Kakitai
Last Friday midnight, there was a large-scale failure in part of the AWS Tokyo region. Some people might have suddenly had to work through the night on a Friday.
This article mentions how, despite having taken measures after a similar previous failure, those measures didn't work as expected in this instance, and includes reflections on that.
I felt that the reality of a service dying "halfway" is something that's hard to truly grasp without experiencing such a failure. I myself realize I had unconsciously assumed that services die cleanly[3].
Referencing cases like this, it's a good idea to think about how to mitigate impacts and how to respond when a failure occurs in a public cloud.
Git Hooks without extra dependencies like Husky in Node.js project - DEV Community 👩💻👨💻
Previously, I introduced the story of Husky giving up the MIT license[4].
By using Husky, each team member can easily enable git hooks for a project. Even without Husky, since Git 2.9, you can configure the use of git hooks in any directory by using core.hooksPath, but it was cumbersome for each team member to make that setting themselves.
This article introduces a method to easily configure git hooks without Husky and run lint-staged at the time of git commit.
When I read it, I thought, "I see, there's this way too." It seems like it would be a good reference for those considering moving away from Husky.
tool
Created an action that can retrieve Runner OS information for GitHub Actions
In GitHub Actions, you can get the OS name of the runner executing the workflow by referencing runner.os. However, runner.os does not include the OS version. Therefore, someone who had a workflow fail due to a bug caused by a difference in OS versions created a GitHub Action that can easily retrieve detailed OS information. This article explains the background that led to creating the Action and the details of how to create an Action.
kenchan0130/actions-system-info: This action provides GitHub Actions runner OS information.
This is a useful Action when you want to get information about the runner's OS. Also, since the article describes how to make an Action in detail, it can serve as a reference for those who are not used to making Actions.
Afterword
This week, there were many topics related to GitHub in general. I also included some in the bonus section. By the way, from this time on, I have started using textlint to continuously proofread the content of my articles. If you are interested, please check out the following scrap.
Every week, our Productivity Improvement Team holds a session to share these kinds of stories. If you're interested in our team, click the link below!
omake
Here are this week's bonuses. I originally intended to have just one, but it turned into two.
You can now turn your GitHub contribution graph into a 3D model!
Exactly as the title says. GitHub has released a site that converts your GitHub contribution graph into a 3D model.
Enter your GitHub username, and you can immediately view your contribution graph in 3D. You can even play epic music. To my surprise, you can share it or download it in STL format. You can print it on a 3D printer right away.
When I hear "Skyline," I think of the Nissan car, but according to Weblio, it means "horizon." Indeed, if you turn the contribution graph into 3D, it doesn't not look like a group of buildings appearing on the horizon.
👻 GhostText — Use your text editor in the browser
Software that allows you to input into text boxes on your browser using any text editor, such as VSCode.
By installing extensions on both the browser side and the editor side, you can input into browser text boxes using your editor of choice.
I tried it out on Twitter and could write code easily. However, I couldn't tweet it directly...
And after using it, I realized, "Wait, wouldn't it be fine to just copy and paste what I wrote in the editor?"...
If anyone knows a good use case for this, please let me know.
-
Of course, if you merge a malicious dependency, it can still cause harm, so this doesn't mean verification before merging is no longer necessary. ↩︎
-
I found it very helpful when I was a university student, using it for studying and referencing terminology. ↩︎
-
This might be relatively common knowledge for those who work in data centers or those close to it (Infrastructure Engineers or SREs?). ↩︎
-
Discussions regarding the license seem to be happening here: https://github.com/typicode/husky/issues/857 ↩︎
Discussion