Closed noelmiller closed 1 month ago
@seanh
I like this approach a lot better. Where would the best place be to update the documentation regarding this? Or do you want to do that as a separate PR?
Oh, I missed this part: "Aside from that, the only other issue I see is adding docs explaining how to test your build without deploying it, but I think that can be done in a separate PR later."
I am still happy to update the docs to explain this, just having trouble tracking down where I can update that in your documentation.
Where would the best place be to update the documentation regarding this? Or do you want to do that as a separate PR?
I'm actually a new contributor to Pelican myself, the GitHub Actions workflow is the only thing I've contributed.
I think you could either add the documentation changes to this PR or do them as a separate PR, either way seems fine to me.
The https://docs.getpelican.com/en/latest/tips.html page in the docs comes from the https://github.com/getpelican/pelican/blob/main/docs/tips.rst file in this repo, so that's the file you want to change. There's already docs in that file about how to use the workflow to deploy to GitHub Pages, so you just need to add a section explaining how to use the workflow to test the build only. Using the workflow just to test the build doesn't have anything in particular to do with GitHub Pages so I wouldn't put the new documentation in the GitHub Pages section. I'd maybe add a new top-level section to the file about using GitHub Actions to test site generation.
Oh, I forgot to say if you would like to preview your changes to the docs locally you can run:
tox -e docs
...to build the docs and then run:
python3 -m http.server -d docs/_build/html/
...to serve the docs, and open http://localhost:8000/
If you have invoke
installed, there is a built-in task for building, watching, and serving:
invoke docserve
Added a new commit to update the docs. Any feedback?
If you have
invoke
installed, there is a built-in task for building, watching, and serving:invoke docserve
Side Tangent: So I went down quite a rabbit hole trying to figure out how to set up my python environment (I am more of a sysadmin than a dev). I'm not sure if this Containerfile would be useful to folks? I work off a Fedora Atomic based desktop Bazzite, so installing dependencies on my local machine is not usually a thing I like to do.
FROM cgr.dev/chainguard/python:latest-dev
WORKDIR /app
ADD ./requirements /app/
COPY tasks.py /app/
VOLUME /app
USER root
RUN apk update \
&& apk upgrade
RUN python -m venv /root/virtualenvs/pelican
ENV PATH="/root/virtualenvs/pelican/bin:${PATH}"
RUN pip install -Ur developer.pip \
&& pip install -Ur noel.pip # Includes invoke we could obviously include invoke in the developer.pip
RUN invoke tools
ENTRYPOINT ["invoke"]
This is what I ended up writing. Not sure how useful it would be? Works great for docs.
To build: podman build . -t pelican-source
To run: podman run -p 8000:8000 -v ./:/app:Z pelican-source:latest docserve
Equivalent docker commands would be:
docker build . -f ./Containerfile -t pelican-source
docker run -p 8000:8000 -v ./:/app pelican-source:latest docserve
@seanh: Any thoughts on the current state of this pull request?
@seanh: Any thoughts on the current state of this pull request?
LGTM, I've tested this with my test site and it works :+1: I would like to rearrange the docs on the tips page but I can send a separate PR to do that later. I think @noelmiller has made a valuable contribution, so I'd say let's go ahead and merge this as soon as you're both happy with it. Might want to squash the commits
I agree with squashing the commits. We went through 2 different refactors, so commit history is a bit messy.
Awesome! Thank you for the feedback and @seanh for pushing it over the finish line :)
:partying_face:
Pull Request Checklist
Resolves: #3403