-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: add publish #52
ci: add publish #52
Conversation
Can we skip the "publish to IPFS/IPNS" step for pre-release releases? That way:
A quick search found this GHA discussion, I don't know if the information is still relevant though. if: "!github.event.release.prerelease" |
I see. I think the current version is good enough. In the ideal world, we would want to decouple "publish to IPFS" from "update IPNS".
It seems like GitHub does not provide an event/trigger to detect when the repository's Latest Release was updated. Maybe that's an oversight worth reporting to GitHub? Maybe it's worth capturing this as a new GH issue in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍🏻
Uploading non-latest IPFS assets isn't yet a requirement, so I don't see a need to split these apart, making the stack more complicated.
Captured in CheckerNetwork/publish-zinnia-module-action#3 👍 |
This automatically publishes the module source ip IPFS/IPNI, when a release has been created. Then, Station Core's auto updater will be able fetch it.
All secrets have been configured on the repo, and stored in 1password with additional context.
Caveat: If we create a new stable release, which is however not the "latest" version, the action will publish it and overwrite the current IPNI pointer anyways. I see this as low risk atm. Do you have any ideas how we could circumvent that?