Ocean-Dynamics-Group / GroupExpectations

A group expectations document.
3 stars 2 forks source link

Create main.yml #11

Open wenegrat opened 2 years ago

wenegrat commented 2 years ago

Working on automating compiling of tex

wenegrat commented 2 years ago

Ok, this currently works by building a pdf and putting it into a new release. I'm basing this on: https://mrturkmen.com/posts/build-release-latex/ and https://github.com/merkez/latex-on-ci-cd

Now, one difference from the above is that it will build on every commit, whereas following the above would only build when a release is tagged. Any comments or thoughts on this @tomchor?

This file can be linked to as: https://github.com/Ocean-Dynamics-Group/GroupExpectations/releases/latest/download/WenegratGroupExpectations.pdf

wenegrat commented 2 years ago

One concern about this is (maybe) releases are independent of branches? So that would seem to say that if people were committing to a branch, it would still update the main document (via the latest release), even if not merged into main?

tomchor commented 2 years ago

I'm not sure I understand when the PDF is built. Is it after every commit that's submitted on any PR? If so, where's that new PDF stored? From your last comment it seems you also have similar questions though.

Although I'm relatively certain that releases are attached to branches. When I publish a new release (or tag a new version) I need to specify what branch that release/tag is gonna be associated with.

I don't have any experience setting up github workflows, but a couple of thoughts are:

wenegrat commented 2 years ago

I'm not sure I understand when the PDF is built. Is it after every commit that's submitted on any PR? If so, where's that new PDF stored? From your last comment it seems you also have similar questions though.

Yes, it's built after every commit, if you click on the latest release you will see the newly generated pdf. For example: https://github.com/Ocean-Dynamics-Group/GroupExpectations/releases/tag/v0.1-8

* If you're planning on not updating this file often, it might be easier to just compile the PDF manually whenever you're about to merge than using CI

Yes that's true :)

* Since you already set-it up, it might be easier to just test it out to figure out what it does. Worse case scenario we create another PR to remove/modify it

I think I understand what it does (aside from the issue of whether releases are attached to branches or to repos). Just not sure whether this is a good idea in practice.