After #2054 the workflow has not been updated and tried to get the fonts
from the old locations.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It went unnoticed now at least 2 times that a release is budgered
because the patch start and end have not been adjusted after expansions.
[how]
Add an --experimental feature that checks the actually patched-in number
of glyphs versus the number of glyphs claimed in the i_*.sh files.
If the new flag is given:
Output the findings. Abort run when mismatch.
Fixes: #2056
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
The previous change was not quite sufficient... a lot stuff has been
forgotten.
commit 6c5f2ad4 casks: Switch to tar.xz archives
Fixes#2041Fixes#1918
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the fonts or the subdirectory structure of a font is changed that
will leave some 'old' files and/or directories in the patched-fonts/
directory. The archiver will try to pack them all and bails out.
In fact on a RELEASE we can safely purge always, because the complete
structure will be regenerated anyhow. The problem with purging exists
only when working locally and patching only some font files.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Update all to latest available today.
According to the release notes I see no hurdles.
But who knows...
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We have an obsolete glyhnames.json in the release FontPatcher.zip.
[how]
Packaging the FontPatcher.zip should be the last step when everything
has already been updated.
Some code from the zip-release.yml workflow is copied into the
release.yml :-/ but we need to do it at the exact right time.
Note that we need to commit-push before we call the
github-pages-deploy-action.
[note]
Related: #1868
Reported-by: @subframe7536
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
With commit
801fb9fe8 Update CascadiaCode to 2407.24
(PR #1844) we dropped the subdir structure of Cascadia Code.
The workflow file did not follow that change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Lately we get an anourmous number of individual icon requests.
Maybe it would be better to explain right there not so high change to
include the icon and point the requester to upstearm projects.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When the icon sets have changed (added or names changed) the i_*.sh
files are (hopefully) up to date, but the glyphnames.json file is only
updated on release.
Unfortunately the font-patcher uses the glyphnames.json to determine the
patched-in glyphs' names, but in the workflow the json file is only
updated after all fonts have been patched.
[how]
Like the version number in the font-patcher file we also create a
transient glyphnames.json in each patching job, that the font-patcher
can then utilize.
Still the in-repo glyphnames.json is only updated after successful
release. So in pinciple we call the generate-css.sh (which also
generates the glyphnames.json) once for every font in the font matrix
(just before patching) and then finally after all patching has been done
again and that is committed back to the repo.
Fixes: #1745
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The Cask-fonts repo has been incorporated into the main Cask repo.
On releases we would use an obsolete repository to create the Cask into.
The casks are now in a dedicated subdirectory (Casks/font) and under that
we have one subdirectory for each font name starting character (to have a
smaller number of files per directory I assume).
[how]
Change the repository path.
Put part of the new (longer) path, the fixed part, just in the CI process,
while the generator script takes care about the one-directory-per-startchar
substructure.
Fixes: #1635
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Suggested now fonts/glyphs/set are usually closed to keep the Issue list
to real Issues and not suggestions. People should be able to further
discuss that addition in the (closed) Issue and it will be evaluated on
the next release.
Anyhow, closing the Issue automatically locks it after half a year and
no discussion is possible anymore. That was not intended.
[how]
Add new tag that keeps closed Issues unlocked and mark the addition
Issues as such.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
I guess it would be good to explicitly state that PRs should be
discussed beforehand, as the disappointment can be big if it is not even
considered for pulling. Prior discussion can also clarify some technical
things that otherwise would need laborious changes afterwards.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
After changing from checkout-files to checkout we can not have two
branches in one place.
[how]
Check the branches out in different directories and merge the needed
files afterwards.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Because we want to use Node 20 etc pp
[how]
Check for breaking changes and update.
Also replace checkout-files by checkout with sparse-checkout; as they
semselves encourage people to do.
action-gh-release has been updated to Node 20 but has not been released
with the change, so we access the latest version directly by hash.
[note]
Of course this is unchecked... what can ge wrong! 😬
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We struggle with the pack-committing of patched fonts to the repository
on release. This makes our repo grow extremely big. It would be better
to just use release artifacts for the releases and not commit any
patched font back.
There were different approaches discussed, but the problem remains that
I personally have no rights to implement anything of that - neither can
I force push to the default branch, nor can I create new repos in the
organization.
[how]
To make it still possible to add new fonts without a repo size
explosion we do not release NEW fonts back to the repository as commits,
but old fonts are handled as before.
NEW fonts:
* have a new property set in the fonts.yaml 'database'
* are released as release artifact via release workflow (but not
committed back)
* get a readme in the patched_fonts/ directory that points to the
release artifact page
The solution is not ideal, but for sure better than not adding any fonts
anymore or having the repo grow in size faster and faster.
At some point in time I would like to phase out all in-repo releases,
also for OLD fonts.
This scheme has been (manually) used / introduced for Intel One.
With this change the .gitignore file is automatically adapted to any new
font that is added with the repoRelease flag set to false (which should
be the default for any added font from now on).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Some fonts will not be released to the repo; but only exist patched as
release atrifacts. This needs adapted readmes.
[how]
If such a font is encountered direct links to the release archives are
put into the readme file.
Decide based on information in the font.json file.
If no info is found in the json file (i.e. all existing fonts) it
defaults to release-also-to-repo behavior.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The dowload turns up empty. This is because we specify a glob while we
need to specify a regex.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Now where we have zip and tar.xz archives one might want to just fetch
one specific one. So we need to have a pattern not only for the
beginning of the file name.
[how]
Enable full regexes for the filtering.
For this we need to escape blanks in the pattern/regex, that a user
might specify (./fetch-archive.sh v2.2.2 'Some Font').
[note]
This is already then used for the casks workflow, as that only needs the
zips.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Previously we had the tag 'master' set in all images, as the images were
created with every push the default branch (i.e. master). Some people
might use that tag for something.
At least we can not remove the last image with 'master' tag, and it will
become outdated immediately, making it a misnomer.
[how]
Add both tags. Hope this works ;-)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font-patcher version of a concrete container is a useful information
if you want to use a not-latest version.
[how]
Add the font-patcher version, that is extracted by grep. Not the most
stable of all solutions but I guess it is good enough.
Fixes: #1267
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font-patcher check workflow fails because the font used for testing
is gone (replaced by differently named one).
[how]
Correct file names.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The variation lists are very long and noone will ever look at them.
Instead we have a font-info.md file, for what reasons?
[how]
Replace the function the font-info.md file had with README.md.
Drop all the variation lists.
Automatically call the readme creation in the gotta-patch-em instead of
just hinting that one should call that (standardize-and-complete-readmes.sh).
[why]
Nowadays the Complete font is the normal font. We already dropped the
partially patched fonts long ago. If someone is self patching they will
know if it is a basic font or a complete font.
And already now one can not see if the patched font is bare minimum
(i.e. Seti, Custom, and Devi) or includes Powerline and/or
PowerlineExtra.
[how]
Just drop "Complete" from the naming.
[note]
As the name changes and thus the file name a lot of the other scripts
will break. But they might break anyhow because other naming changes, so
fix that as last commit.
See also commit
557fc004c Attempt to fix duplicate fonts in fontbook on osx
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we crate a font we take the OriginalName, add "Nerd Font" and which
patches we applied, and add "Mono" if --mono has been specified:
OriginalName Nerd Font Complete Mono
OriginalName Nerd Font plus Weather Mono
But the 'Mono' part is quite important, but this scheme will put it in a
place where it is easily out of view or has been removed (to keep the
name short).
This truncation is especially bad on Windows Compatiple and when the
user installs both the 'Nerd Font' and the 'Nerd Font Mono':
SomeVeryLongFontName Nerd Font Complete
SomeVeryLongFontName Nerd Font Complete Mono
become after truncation
SomeVeryLongFontName Nerd Font Comp.ttf
SomeVeryLongFontName Nerd Font Comp.ttf
[how]
Always put the "Mono" directly after "Nerd Font" and all the other name
components come later.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
