Create main.yml

[wenegrat]

Working on automating compiling of tex

[wenegrat]

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]

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]

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:

• 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
• 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

[wenegrat]

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.