FILE STORAGE Synchronization Feature with GitHub Releases
This is a FILE STORAGE feature to synchronize with releases created on GitHub.
If you wish to sync to File Release, please check here.
What can be done and can’t be done
Go to FILE STORAGE “Admin” page to configure. To navigate to “Admin” page, first, click “Downloads” to show the pull-down menu. Next, click “Admin” under “FILE STORAGE”.
You can configure from “Add sync item from GitHub repository to OSDN.net”, 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, https://github.com/foo/bar. You need to have the admin rights (at least the right to create Webhooks) for the target repository.
Please keep in mind that once 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.)
Here you will specify the directory name, which will be the mirror destination. The moment you type in the name of the repository, a candidate directory name will be generated automatically for you to use it as a reference. (If you like it, you can leave it as it is.)
If the specified directory isn’t there to be found, a directory with a path specified at the time of the first mirroring will be created, and mirrored items will be stored under the directory. Please note that if you specify an already existing directory, all the directories, and files that have been stored there before the mirroring will be deleted.
You can not change the destination directory afterward.
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 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 not, releases that are saved as draft releases on GitHub will not be mirrored.
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. )
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”.
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 directory and the files under it will not be removed and will remain.
If the mirrored items are no longer necessary, remove the destination directory.
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 directory and files under it are still there to remain.
That is a part of the specifications. Even if you delete the sync settings, the directory and files that have been specified by the sync settings are there to remain.
If you need them deleted, you will have to do it 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 FILE RELEASE, and not to FILE STORAGE.
There is a similar feature in FILE RELEASE, so please check here.
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.