[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]
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>
