Update release.yaml (#7)

* Update release.yaml

update v3 latex build
change build-path to hidden '.build'

* Update template.tex

change [h] float specifier to [ht]

* Update build.yaml

Pin texlive to 2023 and force the build.

* Update release.yaml

Pin to texlive 2023 and add force build

* Update build.yaml

Use chktex to lint instead of the heavier build operation.

* a few linter suggestions, we need an autoformatter!

---------

Co-authored-by: Moritz Jörg <[email protected]>

.github/workflows/build.yaml

@@ -14,8 +14,7 @@ jobs:
         uses: actions/checkout@v3
         with:
           fetch-depth: '0'
-      - name: Compile LaTeX document
-        uses: xu-cheng/latex-action@v3
-        with:
-          root_file: src/template.tex
-          args: -pdf -shell-escape -interaction=nonstopmode -output-directory=.build
+      - name: LaTeX linter (chktex)
+        uses: j2kun/chktex-action@main
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/release.yaml

@@ -37,16 +37,18 @@ jobs:
           draft: false
           prerelease: false
       - name: Compile LaTeX document
-        uses: xu-cheng/latex-action@v2
+        uses: xu-cheng/latex-action@v3
         with:
-          root_file: template.tex
-          args: -pdf -shell-escape -interaction=nonstopmode -output-directory=build
+          root_file: src/template.tex
+          texlive_version: 2023
+          latexmk_shell_escape: true
+          args: -pdf -interaction=nonstopmode -output-directory=.build -f
       - name: Upload Release Asset - Template
         uses: actions/upload-release-asset@v1
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:
           upload_url: ${{ steps.create_release.outputs.upload_url }}
-          asset_path: ./build/template.pdf
+          asset_path: ./.build/template.pdf
           asset_name: template.pdf
-          asset_content_type: application/pdf
+          asset_content_type: application/pdf

src/template.tex

@@ -79,12 +79,12 @@
 \maketitle
 
 \begin{abstract}
-	This document describes the most common article elements and how to use the IEEEtran class with \LaTeX \ to produce files suitable for submission to the IEEE.  IEEEtran can produce conference, journal, and technical note (correspondence) papers with suitable class options.
+	This document describes the most common article elements and how to use the IEEEtran class with \LaTeX\ to produce files suitable for submission to the IEEE. IEEEtran can produce conference, journal, and technical note (correspondence) papers with suitable class options.
 	This template is meant as a general guideline on how to write a report, and to give some tips about what you should and should not be writing. You may move or cut sections depending on the assignment or your needs.
 
-	While writing this report template, I enjoyed reading Michael Alley's `The Craft of Scientific Writing'. I recommend having it by your side when you are stuck writing- it happens to all of us \cite{AlleyMichael2018TCoS}.
+	While writing this report template, I enjoyed reading Michael Alley's `The Craft of Scientific Writing'. I recommend having it by your side when you are stuck writing- it happens to all of us~\cite{AlleyMichael2018TCoS}.
 
-	Make sure you clean up the template text before submitting your report. ;)
+	Make sure you clean up the template text before submitting your report.;)
 \end{abstract}
 
 \begin{IEEEkeywords}
@@ -119,12 +119,11 @@ \section{Introduction}
 
 \begin{enumerate}
 	\item This report describes the design and implementation of a list ADT using a linked list. It will go into detail about the design choices made and discuss the benefits and trade offs of those choices.
-	\item Boids is a computer model created by Craig Reynolds that simulates the flocking behavior of birds \cite{TanenbaumAndrewS.2024Mos}. In this report, we present an implementation of the model using the Python programming language.
+	\item Boids is a computer model created by Craig Reynolds that simulates the flocking behavior of birds~\cite{TanenbaumAndrewS.2024Mos}. In this report, we present an implementation of the model using the Python programming language.
 	\item SQL is a widely used querying language used to process queries into table-based databases. This text details the implementation of a simplified server that implements a subset of the SQL language built over sqlite.
 \end{enumerate}
 
-\subsection{Outline}
-\label{Subsection:Outline}
+\subsection{Outline}\label{Subsection:Outline}
 The rest of this paper is organized as follows:
 
 
@@ -141,8 +140,7 @@ \subsection{Outline}
 \textbf{Section~\ref{Section:Conclusion}} concludes and summarizing possible future work.
 
 
-\section{Theoretical Background}
-\label{Section:Theoretical Background}
+\section{Theoretical Background}\label{Section:Theoretical Background}
 This section is where you provide information on the theoretical aspects of your design.
 You can usually assume that the theory required to solve the assignment is known to the reader, but if you want to clarify terms or go into detail about specific points in the theory (if you are doing something slightly different, or a detail of it is of notable importance to your implementation), consider writing a few words about it here.
 
@@ -151,15 +149,14 @@ \section{Theoretical Background}
 
 Here is an example of a subsection covering a topic.
 
-\subsection{Virtual memory}
-\label{Subsection:Virtual_memory}
+\subsection{Virtual memory}\label{Subsection:Virtual_memory}
 The basic concept of virtual memory is that you map the virtual address the processes use to a unique
 physical address in physical memory. This means that two processes can access the same virtual address
 in their address space but get two different results since the addresses point to different
 places in the physical memory. This again means that each process can use all of its 32-bit
 address space while still ensuring that no other processes can access its data~\cite{TanenbaumAndrewS.2024Mos}
 
-Using figures in technical backgrounds is encouraged, if that makes the concept easier to explain. Usually, you want figures/images as Scaleable Vector Graphics(SVG) or Portable Document Format(PDF), especially for your graphs. Sometimes that is not doable, and you can use portable network graphics(PNG) or similar.
+Using figures in technical backgrounds is encouraged, if that makes the concept easier to explain. Usually, you want figures/images as Scaleable Vector Graphics (SVG) or Portable Document Format (PDF), especially for your graphs. Sometimes that is not doable, and you can use portable network graphics (PNG) or similar.
 The following snippet shows how to import figures.
 
 \begin{figure}[htbp]
@@ -177,12 +174,11 @@ \subsection{Virtual memory}
 	\end{center}
 \end{figure}
 
-\section{Design}
-\label{Section:Design}
+\section{Design}\label{Section:Design}
 This is where you describe how you solved the assignment, at least on paper. Give a high-level view of your design.
 As a rule of thumb, if you find yourself describing code, you need to go to a higher abstraction level. If you for some reson want to write code you can use the `listings' package as seen in \autoref{strcpy}
 
-\begin{figure}[h]
+\begin{figure}[ht]
 	\begin{lstlisting}[language=C, style=cStyle]
 /* Simple copy from src to dest */
 char *strcpy(char *restrict dest,
@@ -210,24 +206,21 @@ \section{Design}
 Examples of what the design section should cover:
 
 \begin{itemize}
-	\item The interface of the list ADT supports six methods. These are create\_list(), destroy\_list(), add\_list(), remove\_list(), iterate\_list() and sort\_list(). When a list is created, it is provided with a comparator method that is used to handle sorting{\dots}
+	\item The interface of the list ADT supports six methods. These are `create\_list()`', `destroy\_list()`', `add\_list()`', `remove\_list()`', `iterate\_list()`' and `sort\_list()`'. When a list is created, it is provided with a comparator method that is used to handle sorting{\dots}
 	\item The Boids simulation consists of a set of entities called Boids, Each boid moves independently according to a set of criteria, specified in three rules. Firstly, boids avoid crashing into obstacles, including other boids. Secondly, boids attempt to maintain the same speed and heading as nearby boids. Finally, all boids attempt to move closer to each other to form a cohesive flock.
 	\item The server parses incoming data requests into an SQL query and runs them on its database. The result is then processed into JSON and returned to the client.
 \end{itemize}
 
 
 Remember to avoid low-level details! An expert should in theory be able to implement your design in any programming language based on what you write in this section.
 
-\section{Implementation}
-\label{Section:Implementation}
+\section{Implementation}\label{Section:Implementation}
 This is where you go into detail about your specific implementation. Questions you should answer here are things such as ``How does your implementation match your design?'' and ``Are there any bugs, and do you have any ideas about what may be causing them?''. What sort of difficulties did you experience when working, and how did you overcome them? If you found a clever solution to the problem, this is also the place to write about that.
 
-\subsection{Technical Details}
-\label{Subsection:Technical_details}
+\subsection{Technical Details}\label{Subsection:Technical_details}
 You may want to include a short section giving high-level details about your implementation, such as the programming language used and other information you find relevant for your report. In most cases however, this section is unnecessary, as the assignment usually decides those details for you. Even if you have the freedom of choice, consider whether this information is really relevant to the report, which should avoid low-level implementation details most of the time.
 
-\section{Experiments and Results}
-\label{Section:Experiments and Results}
+\section{Experiments and Results}\label{Section:Experiments and Results}
 A core pillar of computer science is testing. In this section, you should include your methodology for testing your implementation. How do you know your implementation meets the requirements? What sort of performance metrics have you chosen to benchmark your solution, and how did you go about performing tests to gather those metrics?
 
 You should present the results of your tests here, either using an illustration and/or a table of results. These will be valuable in the discussion section.
@@ -253,31 +246,28 @@ \section{Experiments and Results}
 
 If presenting data and benchmarks are not important to the assignment, you may likely find yourself cutting this section. If you decide to do so, make sure you at least mention your correctness criteria and testing methodology somewhere else.
 
-\section{Discussion}
-\label{Section:Discussion}
+\section{Discussion}\label{Section:Discussion}
 The discussion section is the most important section in a report, This is where you show that you understand the theory behind the solution, and also a chance to argue the pros and cons of your solution. You should discuss about the results of your measurements and why you think they are the way they are. Also bring up tradeoffs, and why you made the choices you did; show that you understand the alternatives, and why they may be a good idea (or not) for the particular problem the assignment asked you to solve.
 
 
 Here is an example of a discussion subsection:
 
-\subsection{Recovery of a simulated crash}
-\label{Subsection:Recovery_simulated_crash}
+\subsection{Recovery of a simulated crash}\label{Subsection:Recovery_simulated_crash}
 When a node recovers from a simulated crash, it will check if it's neighbors is still connected to it. If not, it will try and start an internal join to its previous successor. This works as long as the previous successor is still active in the network. The case where the previous successor is not active, is not dealt with, and will result in the node not being able to recover.
 
 
-\section{Conclusion}
-\label{Section:Conclusion}
+\section{Conclusion}\label{Section:Conclusion}
 Here you sum up the report and reiterate the results. Does not need to be very long, a few sentences is fine.
 
 
-\printbibliography
-
-{\appendix[Proof of the Zonklar Equations]
+\printbibliography{
+    \appendix[Proof of the Zonklar Equations]
 	Use $\backslash${\tt{appendix}} if you have a single appendix:
 	Do not use $\backslash${\tt{section}} anymore after $\backslash${\tt{appendix}}, only $\backslash${\tt{section*}}.
 	If you have multiple appendixes use $\backslash${\tt{appendices}} then use $\backslash${\tt{section}} to start each appendix.
 	You must declare a $\backslash${\tt{section}} before using any $\backslash${\tt{subsection}} or using $\backslash${\tt{label}} ($\backslash${\tt{appendices}} by itself
-	starts a section numbered zero.)}
+	starts a section numbered zero.)
+}
 
 %{\appendices
 %\section*{Proof of the First Zonklar Equation}