-
Notifications
You must be signed in to change notification settings - Fork 25
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
Workflows for creating releases with docs #891
base: v3
Are you sure you want to change the base?
Conversation
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.
I'm not a huge fan of having workflows commit directly to the main branch. Why not just create a release associated with the tag that contains the docs and make the docs part of the release?
If we want to go the route of having our workflows commit to the repository, then I think it should be part of a "merge release" which pushes to a release branch, and then contains
- changelogs
- docs
Then that thing gets tagged.
However, if our website needs to be able to switch between API docs versions, then it doesn't make sense to have it in the repository.
Using a release is a good idea and it might be easier. I'll do that |
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.
Question: Do we need the rebuild releases? At the most, it seems like we would need them for 3.0.0
, 3.0.1
, and 3.0.2
Co-authored-by: Charles Lowell <cowboyd@frontside.com>
I guess that's true. I was thinking in case we want to update the releases to a specific format. Like now, I need to rerun, to rebuild at least 3.0.0, 3.0.1 and 3.0.2. In the future, there will be more. I can change the filter to only include non-preview releases. What do you think? |
I'm torn, on the one hand, I feel like releases are releases, and that means a binary artifact corresponding to a specific git SHA. On the other, you're right. What if we need to update urls, or change style? In that case, maybe it's best to have an executable task in the repo that we can do manually? |
The setup I have allows us to rerun the job via GitHub UI. Would you like me to rewrite it to Deno? |
Related #890
Motivation
This PR introduces two GitHub Actions Workflows:
create-release.yaml
This workflow runs anytime a tag is created that matches "effection-v*". It'll checkout the tag, generate docs with
deno doc
, create a tarball and create a release.rebuild-releases.yaml
This workflow can only be triggered manually. It can be used to rebuild all of the releases. It has two jobs: setup & rebuild. The setup job gets a list of all tags that match the "effection-v*" pattern and sticks the result into outputs. The rebuild job uses outputes from setup as matrix. The actual workflow is same as create-release.yaml
TIL
act -s GITHUB_TOKEN="<YOUR_TOKEN>" -W .github/workflows/rebuild-releases.yml workflow_dispatch
can be used to runrebuild-releases.yaml
on your machineTODO