Ignore the "_SITE" path, but GitHub Action reports "No such file or directory..."

[tanchangde]

According to Ignoring Output, I added the "_SITE" path to .gitignore.

My blog can be deployed using 'quarto publish gh-pages', see pages-build-deployment. However, the publish.yml CI will fail, with a failure error, see fix branch.

@cderv

[cderv]

I believe your configuration is not correct https://github.com/tanchangde/tanchangde.github.io/blob/09f26bf74be5cbf32b9848b2232c8bd49faa51e9/.github/workflows/publish.yml#L20-L25

      - name: Publish
        uses: quarto-dev/quarto-actions/publish@v2
        with:
          target: gh-pages
          render: false
          path: '_freeze'

Did you read the README on how to configure ? And look at the examples ?

• You set render: false - so there will be no rendering, and hence _site is looked for. But why are you not rendering ? If your publish does not render, then you need to add a render step. Or indeed add the _site under version control.
• You set path: _freeze - why is that ? This is no a valid value for this option.

---

Also, it is not considered good practice to ping directly someone in an issue unless there is a very specific reason. Your issue will be seen. Please, avoid this in the future. Thank you

[cscheid]

Also, it is not considered good practice

I'll say something stronger. To the original poster and future folks reading, so that the expectations are clear. This is rude behavior, and is borderline outside of acceptable professional behavior, whether or not the original poster intended it. Just don't do it.

[tanchangde]

First, please forgive my inappropriate direct @ behavior, I apologize if I have offended anyone. However, it is not intentional, but a common behavior in my work environment.

After removing render and path in the GHA configuration file, GHA is now able to run normally. Thank you very much for your help.

Did you read the README on how to configure? And look at the examples?

My expectation was that the code would run locally and deploy directly using the results of freeze (at this time, I mistakenly thought the freeze results included rendering), so that I wouldn't have to worry about complex GHA environments and dependency configurations.

I have basically looked at all the examples, and it was based on example-06-no-render.md that I set render: false. Let me organize why I set it this way to prevent others from repeating this mistake.

Initially, I referred to the publish.yml configuration of Publish Action for GHA, but I did not notice to change branches to master. See publish.yml

So after pushing the master branch, GHA did not automatically execute, so I manually executed it once, see 4d824d6, and strangely, after I manually executed it, in my setting of freeze: auto, it actually automatically rendered in the GHA environment and prompted Error in loadNamespace(x): there is no package called 'rmarkdown'.

This is not what I want, so I was looking for updates in the examples that I may have overlooked that can suppress GHA rendering in the cloud. And based on my understanding, the description of example-06-no-render.md seemed very applicable to my situation, so I set render: false.

As for why I set path: '_freeze', this was when I was trying options, the above GHA configuration prompted me that path was also an acceptable input, so I tried it this way. See 02a46e4.

You set render: false - so there will be no rendering, and hence _site is looked for. But why are you not rendering? If your publish does not render, then you need to add a render step. Or indeed add the _site under version control.

I think I may have been influenced by Quarto - Ignoring-output. I mistakenly believed that version control for _SITE was a wrong approach in Quarto globally, so I did not fully understand the situations listed in Quarto - Publishing with Continuous Integration (CI).

Now, I think I understand the connotation of Rendering :)

By the way, I want to report a suspected documentation error I found while dealing with this issue. The background is:

• I have already included the path and files of the Quarto site project created in RStudio in the local master branch
• And, I set up the GitHub repository according to source-branch, and created the orphan branch gh-pages locally
• And, I pushed the local orphan branch gh-pages to remote, but did not push the local master branch to remote.
• And in the remote repository, there is a historically left over master branch.

According to Quarto - GitHub Pages, executing quarto publish gh-pages in the local terminal does not create _publish.yml nor publish.yml, and there are no errors.

[cderv]

To answer about the render: false part. You have two options - we are trying to explain this at: https://quarto.org/docs/publishing/ci.html#rendering-for-ci

Local Execution and Rendering — Run everything in your local environment and then check output (e.g. the _site directory) into version control.

We mention here that you need to check _site into version control if you want to publish the result only.

Local Execution with CI Rendering — Execute R, Python, or Julia code locally and use Quarto’s ability to freeze computational output to save the results of computations into the _freeze directory. Render the site on the CI server (which will use the computations stored in _freeze). Use this approach when its difficult to arrange fully re-executing code on the CI server.

We explain here that an other is to leverage _freeze. You only check in version control _freeze which will contains the results of execution so that rendering on CI does not need executation environment. Though, it still require a quarto render on CI to render the website to publish.

Using _freeze means that if you change you source file, you need to locally re render to update _freeze state. Otherwise, the rendering on CI may try to re-render with execution on CI (if the source file is different than the frozen info). Note that we have currently a bug on local windows for freeze and CI on linux that makes _freeze not working.

Anyhow, one of this solution should be what you are looking for.

Regarding the new issue, I believe we are aware of it and tracking here: https://github.com/quarto-dev/quarto-cli/issues/5686

[tanchangde]

Thank you for your patient explanation, which has helped me find the settings solution that meets my needs.

Looking back on this topic, I have a few suggestions. Given Quarto's rapid iteration, some may be untimely, but I hope you will evaluate and consider:

• Add an explanation to publish.yml indicating that the branches name could be any other value, such as master, to prevent beginners from thinking it's a fixed value.
• For not checked-in _SITE, but render: false set when rendering locally, consider performing corresponding conflict checks and prompts, which might effectively reduce the user's learning cost. At the same time, it would prevent any additional time you may have to spend answering questions due to outdated documentation.
• Enhance the suggested .gitignore entries, for instance, .Rhistory, .RData, .Ruserdata should perhaps not be included in version control for users who build websites using R.
• Regularly invite target users with non-software development backgrounds to provide their opinions or suggestions on various modules of the product. I suppose I have some experience with the Quarto-related toolchain configuration and usage, such as git, github. However, during the configuration process, I still find it challenging, or I need to make a lot of assumptions and attempts based on the document guide.

Finally, I want to express my heartfelt gratitude for your work. You are doing something extremely meaningful, especially as it accelerates the openness and repeatability of scientific research. I think Quarto deserves the compliment of making scientific research better.

[cderv]

Thanks for the very good feedback. We'll see what we can do.

Some of the feedback are tools specific (like R related files in gitignore, or documenting how github actions works). We are trying to be as generic as possible to not skew our doc toward some specific external tooling. We can though add some more links to point to useful resources, or maybe build more examples around all this.

Thanks again for the feedback !