Recent Changes


FILE RELEASE Synchronization Feature with GitHub Releases

This is a File Release feature to synchronize with releases created on GitHub.

What can be done and can't be done

  • You can duplicate source archives and release files, corresponding to a tag created on GitHub, under a package with a designated project name. When there is an update on GitHub, the synchronization feature will add or remove a file or tag/release to follow the update.
    • Instead of following all sequential updates, there is a mode that allows you to execute synchronization only once, at the time of creating the sync settings (or you can also manually choose a time).
    • It can also handle mirroring releases only (and not include source archives matching the tag).
  • It supports public repositories only. (Does not support private repositories.)
  • Project admins can configure sync settings.
    • You must have the admin rights (especially the right to configure Webhooks) for the target GitHub repository. (You can not configure sync settings for any unrelated GitHub repositories.)


Go to FILE RELEASE “Admin” page to configure. To navigate to “Admin” page, first, click “Downloads” to show the pull-down menu. Next, click “Admin” under “FILE RELEASE”.

You can configure from “Add sync item from GitHub repository to”, which is under “Sync From GitHub Release”. You need to configure the following parameters.

Source GitHub Repository

Enter the URL of the GitHub repository which is to be mirrored. It should be in this format, You need to have the admin rights (at least the right to create Webhooks) for the target repository.

Please keep in mind that once the URL is created, it can not be changed afterward. The target GitHub repository has to be a public one. (You can not choose a private repository.)

Destination Package

Here you will name a package, which will be the mirror destination. The moment you type in the name of the repository, a candidate package name will be generated automatically for you to use it as a reference. (If you like it, you can leave it as it is.)

A new package will be created with a package name given at the time of the first mirroring. Please note that you can not mirror to an already existing package.

You can not change the destination package afterward. However, you can change the package name and such from the admin page of the package.

Please note that if you create a release or add a file to a destination package, they will be deleted when the mirroring is performed.

Include Tags

On GitHub, when you add tags to a repository, zip and tar archives that match the tags are generated automatically, and those items can be viewed on the release page. Furthermore, you can create releases based on those tags, and you can name them and can even put files, not including the ones that are auto-generated, in a group.

When running synchronization from GitHub to OSDN, both tags and releases are mirrored as default. However, if you disable the “Include Tags” switch, only the releases are mirrored, and will not include tags.

This configuration can be changed afterward, but please take note that if you change the mirror settings, which originally included Tags, to not include Tags, all the releases and files that were created based on the Tags will be deleted when the next mirroring is performed.

As a side note, releases that are saved as draft releases on GitHub will not be mirrored.

Automatic Sync

If you enable Automatic Sync, whenever a modification is added to a release on GitHub, it will be reflected to OSDN side. (For some cases, it may take a while to reflect changes due to the limitations on the GitHub Webhook feature. This will be mentioned later.)

If you disable it, mirroring will run only once right after you configure the mirror settings, and will not mirror thereafter. (In the list of mirror settings, ones with disabled Automatic Sync will be labeled as “1 shot”.)

You can change this configuration afterward.

Also, whether Automatic Sync is enabled or disabled, you can trigger synchronization manually by clicking the Re-Sync button in the mirror settings.


When you click the Submit button after you fill in everything above, it starts writing the sync settings.

When you configure for the first time, you will go through the authorization process on GitHub to connect an application. Give permission after checking all the requested rights. A webhook, which notifies whenever a tag is added or a release is changed on GitHub, will be added automatically to the repository on GitHub.

As soon as the sync settings are written, the first synchronization starts automatically.

Manipulate Sync Settings

When you look at “Sync from GitHub Release” on the Admin page, there is a list of configured syncs. From here, you can manipulate each set of settings separately.


Whenever necessary, synchronization with GitHub runs automatically, but you can also trigger re-synchronization (Re-Sync) manually. This is useful when you encounter a situation in which an update of a release doesn’t get reflected and cause a long delay due to the limitations posed by GitHub (as mentioned above).

As a side note, Re-Sync request will be put in a queue for tasks waiting to be executed. Therefore it might take some time to start running Re-Sync. (Clicking the button doesn’t make it get executed right away.)

Also, please note that you can not request Re-Sync within 24 hours from the time when the last Re-Sync processing is finished.


You can edit the sync settings, but the only parameters you are allowed to change are “Include Tags” and “Automatic Sync”.

As a side note, it provides you with a link to the destination package. From here, you can jump to the page that lets you check the package and also go to its admin page.


You can delete the sync settings. If you decide that the synchronization is no longer necessary, you can delete the settings from here. However, please note, that once they are deleted, you can not undo the process.

When you delete them, Webhooks installed in the GitHub repository will also be deleted automatically. However, even though this is very rare to happen, there is a case in which the Webhooks remain (for example, it could happen when you try to configure from OSDN to delete the settings while there is some sort of API behavior problem at GitHub). In such a case, you can manually delete them from the GitHub’s Webhook management page.

Also, the destination package will not be removed and will remain as it is. If there are mirrored items that are no longer necessary, you can go to the FILE RELEASE Admin page to manually remove the destination package, releases, and files.


It doesn’t seem to be operating properly.

Currently, this feature is offered as a public beta. We may add modifications or delete/add some features during the process. It is also possible that there are some unremoved bugs.

If you encounter any problems, please let us know via the ticket system.

I updated a release on GitHub, but the synchronization isn’t happening.

There is a mechanism to receive notifications via Webhook regarding changes added to a release on GitHub, but unfortunately due to the limitations on GitHub Webhook feature (to be specific, events such as creating/modifying/deleting a release get notified, but adding to or deleting from a release don’t get notified), there isn’t a way for the system on the OSDN side to precisely learn about those changes immediately.

Therefore, you might have to wait for a week at the longest for the synchronization to happen regarding items added to or deleted from a release. After having edited a release on GitHub, if it doesn’t get synchronized after a while, you can trigger synchronization manually by clicking the sync button on the Admin page.

As a side note, to manually trigger synchronization, 24 hours must elapse since the last synchronization. Be aware of the timing when you execute.

I deleted the sync settings to stop syncing with GitHub, but the destination package is still there to remain.

It is a part of the specifications. Even if you delete the sync settings, a group of releases/files in the OSDN Release package that was synced according to the settings will remain.

If necessary, you will have to delete them manually.

I deleted the sync settings to stop syncing with GitHub, but the Webhook settings seem to be remaining on GitHub.

Normally, Webhooks that were auto-generated from OSDN site will be deleted automatically when you configure from OSDN Admin page to delete the settings.

However, it is possible that you may not be able to delete Webhook settings on GitHub (because, for example, you happened to delete the API permission on GitHub, or you happened to configure from OSDN side to delete the settings while GitHub API was in a state of halt). Even if you failed to delete Webhooks in such cases, the settings will be deleted from the OSDN system. (In this case, after deleting the Webhooks, you will receive a message which includes a warning that Webhooks were not successfully deleted.)

If Webhook settings continue to remain, please configure from GitHub to delete them manually.

I prefer mirroring to Storage, and not to File Release.

We are planning a beta release of mirroring feature from GitHub to Storage, just like we did with File Release. It is coming out soon.

Can you mirror to a chamber?

As of this moment (May 2020), such a feature is not available, and nothing (including the date of offering) has been determined regarding this feature.