[why]
Somehow the license file is missing from the release run.
It is present if I run it on the local machine.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
More often than not (i.e. almost always) I cancel the release workflow.
The problem is that a release workflow will patch all fonts, and all
fonts will differ (at least in the timestamp) and so the repo will grow
A LOT. Usually you want to be really conciously deciding that the growth
is really warranted, and no automatic can do that.
I guess one could trigger rebuilding the zip archives but not commiting
the newly patched fonts back to the repo, but that is also a strange
situation.
[how]
Release has now only a workflow-dispatch trigger, that must be clicked
if a release workflow shall run.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Release workflow for 2.3.0 stopped.
The script generate-webfonts.sh needs fontforge which was not installed.
[how]
Install the (ordinary) fontforge. As we just export the woff we can live
with whatever version is available.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When we rerun (on a release candidate) we end up with an error message:
* Connection #0 to host api.github.com left intact
Tag exists: "v2.3.0-RC"
exists=true
Error: Unable to process file command 'output' successfully.
Error: Invalid format '"v2.3.0-RC"'
##[debug]System.Exception: Invalid format '"v2.3.0-RC"'
[how]
We want to set an output depending on the grep exit code but the grep
output leaks into our value...
Make grep silent.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Fontforge had a new release. There is no particular error it fixes that
we suffer on, but keeping up to date?
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The actions have several warnings.
[how]
Update them all.
For example action-gh-release 0.1.14 runs on node12 which is deprecated.
upload-artifacts 3 also switches to node16 and 3.1.1 removes obsolete
set-output.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
For some reason setting of some variables broke.
[how]
Did not spent any time to find the reason, just rewrote it in a more
readable and debuggable manner and now it works (??!)
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The release run does not work with the fontforge AppImage anymore.
Obviously Github's 'ubuntu-latest' changed :-}
[how]
Install missing fuse.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although all font files of one font (directory) have the same timestamp
the different fonts (e.g. Agave vs Roboto) have still slightly different
timestamps.
[how]
Note the time when the release workflow has started.
Use that as timestamp for all fonts.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
The webfonts are needed for the cheat sheet. When we update the sheet
code we probably need also new fonts.
The fonts might contain fixes also if there is no need for a new sheet,
so they have to be updated on every release.
[how]
Add mini-script that generates the woff's from the latest 'ttf'.
This makes it easier to check the woffs manually.
Let the workflow create the woffs, and push them to the gh-pages.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
This must have been somehow forgotten. I did try if the autogenerated
file works, and it did.
See commit
bcef53da Update cheat sheet
September 2022? I have no recollection at all :-(
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Although we automatically create a new up to date i_seti.sh on all
original-source.otf updates, we do not push it to the repo together with
the font.
[note]
Also include up-to-date i_seti.sh because the workflow will not trigger
until we have new icons and the font does actually change.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Now we can create the casks of some specific release ('latest' in this
case) at will, based purely on the artifact files and on nothing in the
repo. We do not even need to fetch the repo.
This is still some kind of WIP, because we do not have the secrets and
not even a proper homebrew fork in our organization.
THIS WILL NOT WORK out of the box. Refer to PR #1008 to get instruction
on additional steps needed to make this run.
[note]
Remove cask generation from normal release workflow.
Later on the release workflow has to trigger the cask workflow.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
When you have a fork of this repository and push anything to master the
release workflow is automatically run. This is usually not what people
want. They want to push some changes to the fork's master and create a
Pull Request.
[how]
Only run the release workflow on the original repo.
If they really want to create their own release they would have to
remove this line (or adapt).
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Tagging behavior changed with inclusion of the Meta action.
Previously every docker-rebuild has been tagged 'latest', that is now
missing.
[how]
Enforce latest tag.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
Credentials not needed (I guess).
Workflow is never run on pull-requests, so no check needed.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
[why]
checkout-files checks out the last version on the push target branch,
not the version we actually pushed.
checkout clears all the workspace, so out file we want to commit is
lost.
[how]
Use commit hash from just pushed commit.
Use temporary directory outside of workspace to store the file.
Unfortunately we haved to copy back because github-pages-deploy-action
seems to take no absolute paths.
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
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]
If we ever switch the default branch the links would break. So just say
'default branch' directly, whichever that may be.
[note]
CI workflows not changed, I do not know if there is an alias for the
default branch available.
Fixes: #971 (partially)
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>
