- Notifications
You must be signed in to change notification settings - Fork71
WIP: Add a preview-build action for PRs#227
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
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.
Hi Mirek,
I've reviewed the .github/workflows/preview-build.yml workflow, and it's looking great! It's well-structured and aligns perfectly with our goals for automating documentation previews. I have a few friendly suggestions that could further enhance its effectiveness:
- Comments for Clarity: Adding brief comments to complex steps or choices (like the Docker usage) could make the workflow more accessible to others, especially new contributors or those not familiar with specific tools.
- Error Handling: Consider incorporating steps for error handling, such as notifications for build failures. This could improve our response time for resolving any issues.
- Caching Dependencies: If the build process involves stable dependencies, implementing caching could significantly reduce build times and resource usage.
- Security Checks: Ensuring the Docker images and actions are from trusted and verified sources is crucial for maintaining the security of our workflow.
- Workflow Documentation: A short README explaining the purpose and workings of this workflow (and any others in .github/workflows) would be beneficial for maintainability and onboarding.
These are just enhancements to what is already a solid foundation. I'm looking forward to seeing this project evolve how it will improve our documentation process. Great work!
Best, Rolfe
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!
@rolfedh@IanFrangs@emmurphy1 Thank you for checking the PR, but it is far from to be finished. I tried to indicate this by I'm still struggling to realize what URL can I use for deploying preview builds. In the Github docs for deploying PR preview I've checked, I only found After the upcoming RHEL Beta releases are out, I'll try to follow guidance on [2]. And probably on some copy of this repository first. [1]https://github.com/redhat-documentation/modular-docs/blob/main/.github/workflows/deploy-site.yml [2]https://medium.com/@vegaobed/how-to-enable-pull-request-previews-in-github-pages-dc3a94fa969b |
An attempt to add an automatically triggered action that provides a preview build for every new or re-opened pull request.