How to use this tool

[NoiseFan]

Recently, I have been investigating issues related to automatic document migration. At present, I have encountered some problems. If you have time, can you help me answer them?

Question

1. After creating issuse, what operations should be performed? I am not very clear, can you help provide what to do next?
2. does it not automatically create a pr?

Thanks.

Context

yml config

Example of created issuse

[Gumball12]

Hi @NoiseFan, thanks a lot for trying Yuki-no and sorry for the late reply.

I checked your workflow and the issue you linked, and I'll try to answer both questions and also explain where the project is right now.

1. What should I do after an issue is created?

The current stable version is v1 (Gumball12/yuki-no@v1). v1 focuses on detecting changes in the head-repo and creating issues in your translation repo. It doesn't open pr automatically.

The typical flow looks like this:

1. Yuki-no creates an issue in your translation repo with a link to the head-repo commit (like the example you shared)
2. You open that commit in the head-repo and check what changed and which files were touched
3. You apply the same changes to the corresponding file in your translation repo
4. After you've updated the translation, you close the issue

Note that it's usually better to process issues from the oldest to the newest. If you handle newer issues first and then older ones later, an older change can overwrite newer translations if they touch same part of the docs.

2. Does it automatically create a PR?

For the current v1 action, the answer is no: it creates issues (and, optionally, release-tracking comments), but it does not open PRs by itself.

I've been working on a plugin-based system on the next branch that adds extra features. There are currently two plugins:

• @yuki-no/plugin-release-tracking
• @yuki-no/plugin-batch-pr (experimental)

This plugin-based version is still a WIP and is exposed as Gumball12/yuki-no@wip. In the next branch README I accidentally wrote Gumball12/yuki-no@v1 in the example, that's my mistake. If you want to use these plugins, it should say @wip.

So, you can choose between two paths:

Option A - Keep using the stable v1 (sync issue + release tracking only)

If you only need issue creation + release tracking, I recommend staying on Gumball12/yuki-no@v1 and using the options from the main branch README.

In that case, you don't need the plugins option. Instead, you can enable the built-in release-tracking flag like this:

name: yuki-no

permissions:
  # Read external repo changes
  contents: read
  # Create and update issues for tracked changes
  issues: write
  # Get last workflow run info
  actions: read

on:
  schedule:
    - cron: '0 * * * *' # Every hour
  workflow_dispatch: # Manual trigger (Optional)

jobs:
  yuki-no:
    runs-on: ubuntu-latest
    steps:
      - uses: Gumball12/yuki-no@v1
        with:
          # [Required]
          # GitHub access token.
          access-token: ${{ secrets.GITHUB_TOKEN }}

          # [Required]
          # The head repo to track. This is the repository you want to
          # take a diff.
          head-repo: https://github.com/vitest-dev/vitest

          # [Required]
          # The git commit sha of head repo to start tracking. Yuki-no will
          # only track commit from this hash.
          #
          # WARNING: TRACK_FROM commit is not included, tracking starts from
          # the next commit
          track-from: 555c2a2958aa698cad08d756c5f6ac8917319cb4

          # [Optional]
          # List of file patterns to track. Multiple patterns can be specified
          # with newlines. Files matching these Glob patterns will be included
          # in tracking.
          # If empty, all files will be tracked.
          #
          # (Glob Pattern: https://github.com/micromatch/picomatch?tab=readme-ov-file#advanced-globbing)
          include: |
            docs/**

          # [Optional]
          # Whether to enable release tracking.
          # When enabled, Yuki-no will track releases for each issue and add
          # comments about release status. Defaults to 'false'
          release-tracking: true

With this setup:

• Yuki-no keeps creating sync issues
• When releases are cut, the built-in release-tracking option will add comments about whether that change is included in a release

Option B - Try the WIP plugins (sync issue + release tracking + batch pr)

If you want to experiment with automatic PR creation, you can switch to the WIP build and use the plugins:

1. Change the action version in your workflow:

   - uses: Gumball12/yuki-no@wip

2. Keep your existing plugins block and add batch-pr if you want PR automation:

   plugins: |
     @yuki-no/plugin-release-tracking@latest
     @yuki-no/plugin-batch-pr@latest

The batch-pr plugin is still under development, so the behavior might change and it may not always work exactly as you expect.

If you're okay with that and want to try it, please also check the @yuki-no/plugin-batch-pr README for configuration details.

---

If anything above is unclear, or if you see strange behavior (especially with the WIP plugins), feel free to ping me again. Also, sorry again for the late reply. I had some real-life things going on and couldn't focus on this project for a while.

Thanks.

[NoiseFan]

This answer is really perfect, and I believe it will help more people.

Recently, I have been busy too. I forgot to reply to you and say sorry. Thank you for your patient reply.

[Gumball12]

Thank you! I'm really happy to hear it was helpful.