doctrine-website
doctrine-website copied to clipboard
doctrine
Whitelist of paths to run CI on, source/ should not trigger builds
The current content of source/ does not look to influence the build at all, its about the generator code itself. Therefore changing the content of the site should not trigger a build. That can be done with paths filter as docuemtned here https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore and used in ORM for example.
That's what I thought about source too when I created the GitHub Actions workflows, but some rst and html files contain Twig syntax that can break a build even on the smallest careless mistake.
I agree that the whole website build takes some time. I don't know if Twig is the only thing in that directory that can break a build so I wonder if a Twig linter would be sufficient instead of the website build.
What is the content of source/ used for if it does not impact the build ? Isn't it the source for some pages of the website ?
Static rst sites like the contribution page but also "Our Partners" page which contains Twig syntax as part of the build. The directories source and templates seem to share a similar purpose. Break something in one of them (not sure if all of them) and the website build breaks.
@SenseException but even static rst files need to be converted to HTML as part of the build process. the output of the build is a website, not rst files.
@stof Did I wrote something that made it sound like that rst files aren't converted to html by the build? :thinking:
Invalid rST syntax can also break the build. So any rst file requires being processed as well.
Yes, that was one of the main issues I had when I did the updates of the website. Ended up with an EventListener I'm not happy with, but it removed a blocker. As for source, there aren't much files in there that don't need to trigger a website build.
The doctrine/rst-parser in use isn't comparable with the one that GitHub is using. What you see in GitHub is not what you get on the website.
Another vector would be that the docs of all the projects don't necessarily need to be build with a push or pull request, when e.g. a new blog post was added or changes were done to the contributions page. I haven't checked it out yet if the website can be build without fetching all the docs.
If this issue was created due to a long runtime of the website build and preventing to start such a build, #551 should have covered that part. If that's the case we can close this issue.