Refine workflow

[koppor]

This refines the workflow:

• Runs checks also on a tag build - this should ensure that there is no "real" broken release
• Cache installed packages (by using https://github.com/awalsh128/cache-apt-pkgs-action?tab=readme-ov-file#cache-apt-pkgs-action) -- to speed up build
• Use install-texlive's capabilities to cache - no more internal cache handling.
• Removes wrog workflow comments

[cfr42]

This refines the workflow:

Thanks! However, right now, the workflow does something I don't understand at all and is essentially useless. (This is nothing to do with your suggestions, obviously.)

• Runs checks also on a tag build - this should ensure that there is no "real" broken release

Checks are run as part of the tag/release workflow, so running the ordinary checks would only duplicate the same tests, as far as I can tell.

• Cache installed packages (by using https://github.com/awalsh128/cache-apt-pkgs-action?tab=readme-ov-file#cache-apt-pkgs-action) -- to speed up build

Thanks. I'll take a look. Though this doesn't significantly contribute to the time. Almost all of it is spent building the font files and testing them.

• Use install-texlive's capabilities to cache - no more internal cache handling.

Hmm. I could not get this to work with two caches, but probably I missed something.

• Removes wrog workflow comments

Indeed. The comments don't bear much relation to anything, I realise.

Thanks again.

[koppor]

This refines the workflow:
Thanks! However, right now, the workflow does something I don't understand at all and is essentially useless. (This is nothing to do with your suggestions, obviously.)

I thought the same - I just worked on the pieces I understand. 😇

• Runs checks also on a tag build - this should ensure that there is no "real" broken release
  Checks are run as part of the tag/release workflow, so running the ordinary checks would only duplicate the same tests, as far as I can tell.

I was very naive. My thought:

There is a workflow for checks. That workflow will surely be adapted in the future. The "release" workflow will surely focus on getting a release out - not focus on advanced testing. Advanced testing is one in the "checks" workflow. - And the checks should run on releases, too. -- Even if tests are doubled, better accept the time than be sorry that there might be a diff in the results.

• Cache installed packages (by using awalsh128/cache-apt-pkgs-action#cache-apt-pkgs-action) -- to speed up build
  Thanks. I'll take a look. Though this doesn't significantly contribute to the time. Almost all of it is spent building the font files and testing them.

Sure. My thinking: This simplifies the workflow. - Action info: https://github.com/awalsh128/cache-apt-pkgs-action?tab=readme-ov-file#cache-apt-pkgs-action (it is currently maintained and did work well even in non-maintained phases)

• Use install-texlive's capabilities to cache - no more internal cache handling.
  Hmm. I could not get this to work with two caches, but probably I missed something.

At https://github.com/gi-ev/LNI/blob/main/.github/workflows/check.yml it worked well.

Example run: https://github.com/gi-ev/LNI/actions/runs/13235264886/job/36938920765

• Removes wrog workflow comments
  Indeed. The comments don't bear much relation to anything, I realise.

I can remove even more, but I did not dare to do so ^^.

[cfr42]

• Runs checks also on a tag build - this should ensure that there is no "real" broken release
  Checks are run as part of the tag/release workflow, so running the ordinary checks would only duplicate the same tests, as far as I can tell.

I was very naive. My thought:

There is a workflow for checks. That workflow will surely be adapted in the future. The "release" workflow will surely focus on getting a release out - not focus on advanced testing. Advanced testing is one in the "checks" workflow. - And the checks should run on releases, too. -- Even if tests are doubled, better accept the time than be sorry that there might be a diff in the results.

I don't think it is naïve. Normally I'd agree; it is naïve to think I won't screw up rather than the contrary. But perhaps you are unfamiliar with l3build?

l3build will not create a release without rerunning checks and recompiling documentation. Feature requests to circumvent this design receive extremely short shrift from Joseph Wright (who usually otherwise at least pauses before saying no). So, in the case of l3build I don't think it is necessary to run the check workflow when a release is built.

Unfortunately, this didn't stop me building a completely broken release, but two erroneous sets of checks would do me no more good than one.

I also currently only push tags on their own. Mostly because I don't really understand git, but also because I try not to create an svn tag until I'm actually going to release and I usually only then tag the git version.

[And, yes, it is daft to use both svn and git for the same code simultaneously, but I do not trust myself with git whatsoever.]