Mirror the raycast/extensions repostiory and publish them automatically to the package registry

Yukaii commented 1 year ago

Steps

TBD ~~Use a workflow to sync repository to the forked repository blast/extension~~

Possible solutions...

The Raycast team runs the "publish" action with every new commit from branch main. Since it is a built-in action event on GitHub and run by the workflow inside the repository, they can ensure that the action runs with every commit. [^1]

If I manually or automatically mirror the raycast/extensions repository, the synchronization status (i.e., the last commit that was synced) must be stored somewhere, and generating the differences (i.e., determining which extensions need to be updated) will be more complex.

Alternatively, if I fork the raycast/extensions repository and replace the actions it runs, and handle git merging within the GitHub action context, I would still need to track the last synced commit [^2], then push each commit in between one by one to the forked repository, ensuring that every "publish" action is enqueued. ~~Additionally, if the synchronization process is run periodically as a workflow, I would need to ensure that only one synchronization workflow action is running at a time.~~ [^3]

[^1]: However, there may be a race condition where, for example, commit 1 changes extension A and commit 2 also changes extension A. In this case, the publish action triggered by commit 1 might run after the action triggered by commit 2, causing the latest published extension to be reverted back to commit 1. But since pull requests are manually merged, this scenario is unlikely to occur. (maybe?)

[^3]: GitHub Actions supports only run one job at a time, so it will be fine

[^2]: Can it be stored as JSON artifacts?

Yukaii commented 1 year ago

TLDR: 貫徹免費仔的架構需求好難設計啊

Yukaii commented 1 year ago

Other Ideas

Just zip the ray build result all at once to a repository and download them?

Hard to implement upgrade/downgrade of an extension.
How about metadata extraction?

Why hosting our own extension distributions instead of using existing store RESTful API?

It's unofficial
DIY good 👍

Yukaii commented 1 year ago

GitHub CLI playground

Create a PAT with the scopes: repo, read:org, read:packages. Copy it to clipboard
Run pbpaste | gh auth login --with-token

https://docs.github.com/en/rest/packages?apiVersion=2022-11-28#list-package-versions-for-a-package-owned-by-a-user

gh api \
  -H "Accept: application/vnd.github+json" \
  "/orgs/BlastLauncher/packages?package_type=npm"

# It takes 0.8 seconds to load, not sure if it's due to the network latency...
gh api \
  -H "Accept: application/vnd.github+json" \
    "/orgs/BlastLauncher/packages/npm/todo-list/versions"

So there no API to list all packages with versions Q_Q. For batch upgrading extensions, I'll still need one API server to cache cache packages states on GitHub.

Yukaii commented 1 year ago

Requirements

[x] A CLI that can meet ray-cli action needs,
[x] An action for syncing repository changes.
[x] A GitHub action that utilizes the CLI

Links

Some resources maybe useful when creating the CLI with nodejs

pkg and pkg-action
ncc
The tiny meow would be enough

Note

In the first thread, I said I would still need to track the last synced commit, I found that it's not needed anymore, because in ray action they use tj-actions/changed-files that has a since_last_remote_commit option(Search INPUT_SINCE_LAST_REMOTE_COMMIT in diff-sha.sh). But we still need to deal with the merging the commits to the fork. Something like chery-picking every commits in between to fork repo and push them at once.

Yukaii commented 1 year ago

The first part is completed at sync-upstream.yml.

Second part is about to build a blast-cli that can build and changed raycast extension to GitHub Packages.

BlastLauncher / blast