Thank you, but we don't want to include PDFs in the source repository. You will notice that we attach PDFs to the labelled releases already, and PDFs appear in the public mailings as well. (We are in fact in the process of deleting the existing, historic PDFs from the repository.)

Thank you, but we don't want to include PDFs in the source repository. You will notice that we attach PDFs to the labelled releases already, and PDFs appear in the public mailings as well. (We are in fact in the process of deleting the existing, historic PDFs from the repository.)

I did not add any PDF to the source repository and it will not end up there once this request is accepted.

Ah, I see. Where does the PDF go?

Ah, I see. Where does the PDF go?

It's an artifact attached to the build results, which I assume means we can easily view the result of applying a PR without needing to checkout the branch and build it locally.

I'm not convinced this is necessary or desirable. How long do those artefacts stay around?

Please at least squash your branch and force-push. Eight different commits for a five line change is unnecessary.

How long do those artefacts stay around?

Quote from https://github.com/actions/upload-artifact

"Artifacts are retained for 90 days by default."

We can change that per-repo; I think 14 days should be enough.
I've just changed the repo-wide maximum to 30 days.

"Billing is based on the raw uploaded size"

It seems our plan at github has 2 GB of actions space included.

@tkoeppe, I think we should squash and merge this and try it out. If it doesn't work or costs a lot, we can remove it at any time.

Hm, the artifact is currently delivered as zip file, e.g. see https://github.com/cplusplus/draft/runs/2962468115. Is that what you want? Is there a way to make the PDF available directly?

Hm,

There is currently no way to download artifacts after a workflow run finishes in a format other than a zip or to download artifact contents individually.

I suppose not. OK. Let's try this out, it seems like it could be useful. Thanks!

Hm, the artifact is currently delivered as zip file, e.g. see https://github.com/cplusplus/draft/runs/2962468115. Is that what you want? Is there a way to make the PDF available directly?

You could add another step to upload it somewhere else, of course. I do not think it is necessary. I just wanted to prevent a situation where everybody forks and builds just to get the PDF.

I just wanted to prevent a situation where everybody forks and builds just to get the PDF.

I don't consider that a suitable use of this repo. "Everybody" should not need the latest working draft, and we do not need to provide them with it (they can already get a recent one from the monthly mailings at https://www.open-std.org/jtc1/sc22/wg21/ if they want a recent draft).

If somebody really needs the very latest draft then they should build it themselves.

I don't consider that a suitable use of this repo. "Everybody" should not need the latest working draft, and we do not need to provide them with it (they can already get a recent one from the monthly mailings at https://www.open-std.org/jtc1/sc22/wg21/ if they want a recent draft).

If you want that to happen, you should say so in README.

The project's "About" already links to it, but we could make the README more explicit.

This repo is for managing the sources, not publishing the drafts, and not for end users to easily obtain drafts.

If the purpose of this pull request is to publish the latest draft for users, then I object and want it reverted.

I've been thinking that it'd be nice to have a diffpdf output on PRs done by CI. This PR could be considered a step towards that.

Hm, the artifact is currently delivered as zip file, e.g. see https://github.com/cplusplus/draft/runs/2962468115. Is that what you want? Is there a way to make the PDF available directly?

You could add another step to upload it somewhere else, of course. I do not think it is necessary. I just wanted to prevent a situation where everybody forks and builds just to get the PDF.

Hm, all it would take here is to clone this repo. If people really fork everything at the drop of a hat, there's probably not much we can do about that.

I also changed the artifact name to "draft-snapshot", since the things on this repo aren't even working drafts. Working drafts are the PDFs that appear in the public mailing and are approved by the comittee.

It's good we make sure those PDFs are not marketed as "working drafts". Also, note that they are snapshots after applying pull requests, so become effectively stale after the pull request is merged.

It seems that offering the PDFs is a no-cost operation for everybody involved (including the editors), once we've overcome the discussion in the present pull request, so let's just do that.

(My opinion will change drastically if github actually starts charging for the PDFs in any way.)

It's good we make sure those PDFs are not marketed as "working drafts". Also, note that they are snapshots after applying pull requests, so become effectively stale after the pull request is merged.

I do not think they should be marketed at all. GitHub users will know where to find them, everybody else will have the README nicely updated by @jwakely, and that is that.

@jensmaurer: the artefacts are also available on the main branch actions, so there's a "post-commit version", too.