The Rolling version number was previously set as the result of a
`date` command, implicitly using server time (as of the time the CI
build was running, in the time zone of the server), meaning the
version number could be different based on server timezone across many
regions the CI could happen to run in, based on the timing of re-runs,
or change due to slight differences in how runners were allocated to
run each job.
Most notably, this could lead to the different OS/arch builds having
different version numbers from the same overall CI build, since they
ran in separate tasks!
Now that we have multiple CI providers building the editor binaries,
we have rather drastically different timing of these runs, and the
version numbers are likely never going to sync up.
---
By setting the version number from the commit date, always in UTC,
Rolling versions on Cirrus should now always sync up
with an existing version as published from GitHub Actions.
This also means we can check the commit dates of recent commits to
`master` branch in order to know which exact commit a given Rolling
release version corresponds to.
---
This idea was worked on by a few people, and also thanks to this
StackOverflow answer:
https://stackoverflow.com/questions/21363187/git-show-dates-in-utc
Co-authored-by: Meadowsys <blazeykirin@gmail.com>
Co-authored-by: confused-Techie <dev@lhbasics.com>
Cirrus: Don't update last good commit if CI skipped
Makes it so Cirrus Rolling doesn't skip, so we actually have
Rolling binaries/releases for ARM Linux + Apple Silicon again!
For builds that are effectively skipped, since their tasks are all
skipped or not scheduled in the first place, we shouldn't update
CIRRUS_LAST_GREEN_CHANGE.
Unfortunately, Cirrus *does* update that for builds with no or
all-skipped tasks, for now. They may fix it in the future, we have a
feature request open for it. But for now, this is the workaround.
Previously, we threw an error when a scope adjustment violated its bounds constraints, but that's a bit disruptive for everyday use. Instead, we throw an error in dev mode (so that the grammar's author doesn't fail to notice the problem), but downgrade it to a warning outside of dev mode so that it's recoverable.
There's a chance that the warning will be _too_ subtle, but we'll give it a shot.
We also include more diagnostic information so that it's clearer exactly _where_ the violation is happening.
Remove both `getAppName` and `getReleaseChannel` into `getAppDetails`. Move consumers over to new module. Rewrite config file path logic into shorter function, and move known users of this logic to new module
Stop inserting a best-guess `repository` field for built-in themes'
package.json data if they lack one in their actual package.json file.
Follow-up to https://github.com/pulsar-edit/pulsar/pull/264.
Doing this for the themes panel as well, since we just did it for the
installed-packages panel, and since it's good to be consistent.
We were trying to filter for a certain PR label before,
but inadvertently checked the wrong env var,
based on interpreting some guidance we got from Cirrus team.
In researching what it should be instead, it occurred to me we can
indeed use the `CIRRUS_TAG` env var to check for *any tag push*,
which should actually do pretty well at filtering for releases
after all, since releases are the only times we really push tags.
