Well, ... we need to fetch the git repo, as the deploy action needs it.
Which is documented... :-}
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
A lot of the stuff in the gh-pages is not yet automatized.
See bin/scripts/README.md items with "[3]".
[how]
Start at least with the fonts database file.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When so svg files could be optimized we still try to commit the
'changes'. There are no changes - so nothing is committed (empty commits
are avoided).
But the workflow run still shows the 'commit back to repo' step,
although we know beforehand that it will not commit anything.
[how]
Technically that is no problem and the behavior is unchanged, but we can
just skip the commit step if we know there can not be anything to
commit...
It just looks nicer :-}
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Despite commit
cc2b54770 generate-original-source: Remove FFTM table
we still get unneeded font rebuilds.
The reason is that the font creation time is not only encoded in FFTM but
also in HEAD.
[how]
We could simply diable timestamps also in HEAD, but that would leave us
with a strange font; strange because no one knows when it has been
created.
Instead we take the more laberous route here: Do detect changes and not
rely on the git history:
* Find out current font's creation date
* Create the font anew with that date as creation date
* If the 'real' font content is unchanged we would now have a 100%
identical new font file; we can detect that with `git diff`
* If it is not identical, something apart from the timestamp has
changed and we create the font again, this time with the real current
time as timestamp and commit that file back to the repo
This only works if creation and modification time are always the same on
all font creations; we need to ensure this by always using the
SOURCE_DATE_EPOCH method, even for 'normal' font creation.
This is a bit more involved than what I would have hoped for, but there
seems to be no easy solution.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Often the SVGs are rather detailed and result in a big
original-source.otf, which then again results in bigger than needed
patched fonts.
[how]
Typically people suggest using svgo to make SVGs smaller, but that just
tackles the representation of the icon, i.e. the actual svg file. That
does not help us at all. We do not need small svg files, we need simple
icons with few points and lines. svgo does not have that capability.
Instead Inkscape's 'Simplify' is used. Repeated use can destroy a glyph,
so we need a scale down margin to stop 'over-simplification'.
The values given for the margin at the moment are purely empirical, the
current glyphs survive repeated use of the new simplification script and
still look good.
The resultant original-source.otf file size is approximately similar to
the previously achieved by Ryan's manual work.
[note]
We need a newer Inkscape, thus update to Ubuntu 22.04
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The add-and-commit steps are so unbelievable slow.
[how]
We do not need the other tags, so we do not need a fetch before adding.
See comments on the action's homepage.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The casks-artifact is empty.
[how]
Supply the correct path for the upload.
For this the generator script prints the output pathname(s),
which in turn are used in the CI.
Also drop unneeded '/' from path end.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We create the release packages one by one in a lot of jobs. Whenever a
job is ready it adds its package to the release.
This means that the release starts with one archive and grows over the
next 5 (!) hours. (Noto takes about 5h to patch.)
But people will be notified and find the new *unfinished* release, which
can raise questions or problems.
[how]
Mark the release 'draft'.
Unfortunately I can not find (quickly, now) a way to un-draft the
release so this has to be done manually. Maybe it is better anyhow, so
that one can edit the release message etc.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
I am sure I tested it and it worked. Well, it does not, it throws an
error message
Unrecognized named-value: 'secrets'
[how]
Secrets can not be used in the `if`, see
https://github.com/actions/runner/issues/520
But they can be used in `env`, ... so do it there.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
On forks for example they might have a docker repo associated or not.
The release process is run in any case and will fail in that cases.
[how]
Check that at least the secret is known.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The docker image should be rebuilt whenever a file that will end up in
the container has been changed. So this needs to be in line with the
.dockerignore file.
[how]
Add missing (new) `font-patcher` sub-scripts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
`grep` and `awk` do not know json. This might break if some format
changes or whatever.
[note]
The font matrix setup is also with `jq`.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Usually release tags and versions start with a "v", and we also had that
up to 2.1.0:
$ git tag -l
2.2.0-RC
FontPatcher
v0.1.0
v0.1.1
v0.1.2
v0.2.0
v0.2.1
v0.3.0
v0.3.1
v0.4.0
v0.4.1
v0.5.0
v0.5.1
v0.6.0
v0.6.1
v0.7.0
v0.8.0
v1.0.0
v1.1.0
v1.2.0
v2.0.0
v2.1.0
[how]
In the files we keep the non-"v" version numbers, but the tags on github
shall be prepended with a "v" like "v2.2.0-RC".
The variable RELEASE_TAG_VERSION is renamed to RELEASE_VERSION to make
clear that this is not the name of the tag.
Where we reference a tag, "v$RELEASE_VERSION" is used.
[note]
One of the environment variable is not needed, we can use the output directly.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The release workflow is triggered on a lot occasions, but not on changes
of the package.json file. But that file contains our version number and
when we change it we should create a new release. At least is that how I
would imagine it working.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The fontconfig and cask generation seems unfinished or broken.
[how]
Fix the point in time when the fontconfig is generated and commit any
changes back to the repo.
Generate the casks and store them as CI artifacts at least.
Probably they should be uploaded to the cask repo (on 'real' releases)?
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The release CI is run every time something is pushed to master. This is
useful if we are on a release candidate. The release will be updated.
But if we do a normal release and afterwards push some new commit to
master - before we update the version in the package.json to a RC - the
actual (fixed) release will also be updated.
[how]
Determine if we have a
* new normal release
* new prerelease
* updated prerelease
and run the release process itself only in that cases.
[note]
The release is checked for via API instead of an action, because the
typical action needs a complete checkout (works on the local git repo).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When people check the repo out at a release tag they expect to get all
the files that are IN the release.
But we add the patched fonts and the version-bumped scripts only
afterwards.
[how]
Just overwrite (shift) the tag after everything is finished.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We check the whole repo out, just to set up the font matrix.
All data is thrown away afterwards. That takes needless time.
[how]
Just check out the two files we really need for the setup (the script
and the database).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We need the release tag version in all jobs.
[how]
Instead of determining it in every job again and again (with the same
code) we set an output in the first job and reuse it everywhere.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
This can not work.
Issue 1:
It is unspecified in which order the font matrix jobs run, so the
version number changes somewhen.
The changed (version-bumped) files are never committed and written back,
so this would have to be done manually anyhow.
The version-bump script itself has issues because the regexes for the
change are a bit too loose and other version like strings are changes
also (like the Script Version).
Issue 2:
The script changed versions that should not be changed like the script version
in the scripts (rather than the NF release version).
In bin/scripts/generate-glyph-info-from-set.py pumping has been
forgotten/omitted completely.
[how]
In the version-bump script:
* Use more modern regex
* Instead of copying the code use a loop
Create a commit with the bumped version information in all scripts.
This can only be done with the final job, because we have a problem to
checkout the modified version with actions/checkout.
We need to bump the version on every patch job, because we need the correct
information already in the script when we patch.
[note]
This does not prevent to have multiple commits attempts that change to the same
version. But if the change is empty, no commit will be added and the
step is silently ignored.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The self-written upload-archives script is some issues, for example it
does not replace preexisting release files with new ones when a release
is re-triggered. The error messages are rudimentary at best.
[how]
Use https://github.com/softprops/action-gh-release instead.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Fonttools, FreeType, and HarfBuzz are not used in the CI job.
Propably a leftover from thomething done in the past?
[how]
Because I can not find out the reason WHY they are there the lines are
kept and just disabled. This leaves a nice 'stub' for git blame in the
file.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
We 'manually' patch the font file after `fontforge` created it. This can
go wrong, for example we fail to create a correct new checksum.
Or we fail to patch the correct font property.
[how]
Also build `showttf` from the `fontforge` package and use it to extract
some font properties:
* Check the example patched font file checksum
* Compare the `lowestRecPPEM` of source to patched font file
[note]
`fontforge` set `lowestRecPPEM` always to 8 in generated fonts.
Hack has a value of 6.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
It might be easier to use the precompiled application than to build it
ourselves.
[how]
The AppImage has the typical problem with relative paths, so we need to
change some small calls.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The purged (obsolete) files are still existing after release.
[how]
We restore the deleted files before it adds the new ones.
Just delete all font files and then download all the release files (all
newly created fonts).
`git add` on a directory will remove all missing files.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Fontforge 2020 March or 20th Anniversary have problems to generate fonts
with a lot of table entries. This is for example the massive entries for
ligatures in Iosevka. We can not generate valid font files with that
fontforge versions. We can not even detect (from Python side) if
fontforge had problems.
[how]
We fixed fontforge itself upstream with
https://github.com/fontforge/fontforge/pull/4883
That fix became available first with Fontforge March 2022 Release.
We could use the AppImage or build from scratch, because no package is
available on Ubuntu 20.04 or 22.04.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The font matix contains the directory names of the font files. The
directory names are taken from
bin/scripts/lib/fonts.json
and specifically extracted with
bin/scripts/get-font-names-from-json.sho
That script returns the .folderNames
Later in the release script we use the folder name to limit the fonts
that patch-em-all shall process. Unfortunately patch-em-all could (until
the previous commit) just work with font-filenames and not with
directory names. But the matrix gives us just directory names.
This is for example a problem with this fonts:
$ ll src/unpatched-fonts/BigBlueTerminal
-rw-rw-r-- 1 fini fini 25632 Jan 1 14:03 BigBlue_Terminal_437TT.TTF
-rw-rw-r-- 1 fini fini 69964 Jan 1 14:03 BigBlue_TerminalPlus.TTF
The *directory* of that fonts is correctly noted in fonts.json as
"BigBlueTerminal" but the font files do not begin with that!
[how]
Now, that patch-em-all can also filter on the directory name, we just
need to utilized that in the workflow run. If the filter shall work on
directory names the first character needs to be a slash, so we just
prepend it to name we got from the matix.
Fixes: #824
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
