Skip to content
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

Automation #2

Closed
cansavvy opened this issue Apr 10, 2024 · 18 comments
Closed

Automation #2

cansavvy opened this issue Apr 10, 2024 · 18 comments
Assignees

Comments

@cansavvy
Copy link
Contributor

@howardbaek To start getting this repo truly OTTRized we'll need to transfer the files from https://github.com/fhdsl/OTTR_Quarto/tree/main/.github to here.

Then we'll need to go through the workflows and adapt the steps but before I can help you do that I have two questions:

  1. Does quarto render re-render this site or would it be a different command?
  2. What's the easiest way to remove the TOC? We'll need a TOC-less version rendered for Coursera and Leanpub purposes.
@howardbaik
Copy link
Contributor

Have a render toc-less version that doesn't have TOC. We need both copies (so we can put the iframe in coursera/leanpub).

@howardbaik
Copy link
Contributor

@cansavvy @carriewright11

Easiest way to remove TOC and sidebar is to add this field inside _quarto.yml:

format:
  html:
    sidebar: false
    toc: false

@howardbaik howardbaik changed the title Automation adaption Automation Apr 15, 2024
@howardbaik
Copy link
Contributor

@cansavvy what is the rendering approach that the original OTTR_Template takes?

From https://quarto.org/docs/publishing/ci.html#rendering-for-ci

Screenshot 2024-04-15 at 5 22 55 PM

The first option places minimal requirements on software that needs to be present on the CI server, the second option seems really simple to do with Quarto's ability to freeze computational output, and the third option doesn't seem feasible since each user of ottr will have different dependencies and we can't capture all these dependencies on a CI server.

I just want to stay consistent with what the original OTTR does.

@cansavvy
Copy link
Contributor Author

OTTR renders everything through CI - that's what we use GitHub actions for.

Folks can render it locally but honestly it's unnecessary and just makes things muddier.

@howardbaik
Copy link
Contributor

So, does the second option, Local Execution with CI Rendering, work?

@cansavvy
Copy link
Contributor Author

Unlike what is described here we don't use renv to handle our dependencies we use docker to handle our computing environments so everything is pretty tightly enforced.

@howardbaik
Copy link
Contributor

howardbaik commented Apr 16, 2024

Are you saying that we can go with the third option but, instead of renv, we can use Docker to handle dependencies?

@cansavvy
Copy link
Contributor Author

I'm a bit confused by your question. Most of the automation you'll need as far as basic quarto rendering should be ready to go by just copying what I have set up for quarto rendering here: https://github.com/fhdsl/OTTR_Quarto/blob/766b7e6ed3166216e611724124354c2b7feacce2/.github/workflows/render-site.yml#L56

But if this doesn't clear things up we should chat so we can figure out what's needed.

@howardbaik
Copy link
Contributor

Quarto has custom GitHub Actions here: https://github.com/quarto-dev/quarto-actions that I want to use.

I'll setup a time to chat and talk over things.

@cansavvy
Copy link
Contributor Author

Sounds good! Let's chat.

Meanwhile, what features from the quarto actions are what you want to use with OTTR?

@howardbaik
Copy link
Contributor

I was thinking of these two actions:

  • quarto-dev/quarto-actions/render@v2
  • quarto-dev/quarto-actions/publish@v2

@cansavvy
Copy link
Contributor Author

Can you describe what these actions are doing that makes them something we want to use with OTTR?

@cansavvy
Copy link
Contributor Author

@howardbaek We figured out a more concrete (but still somewhat amorphous) strategy on our call.

Chunk 1) Go to OTTR_template and make render_type a new option in the config_automation.yml as well as the render-all.yml file. File a pull request here. We want the options to be "quarto" or "rmd" at this point. See file I sent you with the highlighted areas of the render-all.yml file that need changing.

Chunk 2) We'll need to have these changes carried through to the ottrpal package in the render_without_toc function. Here we'll also make a new argument that tells whether its quarto or rmd. Default should be rmd for now so people's repos don't get broken. I will link the branch in ottrpal that has the initial mapping I did to those files to add this argument.

@cansavvy
Copy link
Contributor Author

Here's that branch @howardbaek https://github.com/jhudsl/ottrpal/tree/cansavvy/quarto

Feel free to bug me (or schedule time with me) about any of this that isn't clear because I know we had to wrap up our call before we really got it figured out.

@cansavvy
Copy link
Contributor Author

This has turned out to be a trickier thing than I originally thought!

@howardbaik
Copy link
Contributor

Thank you for documenting this. I will bug you if I have a question!

@howardbaik
Copy link
Contributor

I found a very simple way to get rid of TOC and the sidebar (the bar on the left):

quarto::quarto_render(".", metadata = list(sidebar = F, toc = F))

@cansavvy
Copy link
Contributor Author

I found a very simple way to get rid of TOC and the sidebar (the bar on the left):


quarto::quarto_render(".", metadata = list(sidebar = F, toc = F))

Love it! Very clean!!

@howardbaik howardbaik linked a pull request Apr 17, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants