Adds a step to the release and run_bundling workflows to build a
statically-linked bubblewrap binary and upload it
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Tom Houlé <tom@tomhoule.com>
# Objective
We were not caching builds for nightly/bundling jobs AT ALL.
## Solution
## Testing
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Pins the remaining tag- and branch-referenced GitHub Actions and the
`postgres` service image to specific commit SHAs / digests, so workflow
runs resolve to fixed versions. Edited in the xtask workflow DSL and
regenerated with `cargo xtask workflows`.
- `bufbuild/buf-setup-action` → `a47c93e0` (v1.50.0)
- `bufbuild/buf-breaking-action` → `c57b3d84` (v1.1.4)
- `digitalocean/action-doctl` → `3cb39531` (v2.5.2)
- `postgres:15` → `@sha256:1b92e7a8…`
- `deploy_docs.yml` reusable workflow → pinned to a commit
Release Notes:
- N/A
This updates the nightly workflow to run hourly as opposed to once
daily.
Notably, it also
- changes the poll duration for the auto updater - we now poll 4 times
an hour on the Nightly channel and continue with the old rate for all
other channels
- moves the pre-checks to the linux runners, since we have more
resources available there
- only ever allow one concurrent nightly run
Release Notes:
- N/A
https://github.com/zed-industries/zed/actions/runs/25881329418 complains
about the deprecation of Node.js version 20, which will soon be
force-bumped to 24 in the runner contexts.
Thus, this PR bumps all the jobs mentioned there to versions that run on
Node.js 24 by default. I checked all the release note section for the
three actions and this should not change any behaviour according to
their release notes and get us ready for the deprecation.
Release Notes:
- N/A
This relies on 1.94s --workspace option we've added to cargo
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
The workflow run at
https://github.com/zed-industries/zed/actions/runs/23557683707 succeeded
but threw some warnings for a rather-soon Node.js 20 deprecation (June
2nd).
Hence, this PR updates in that context mentioned workflows to newer
versions from which on the actions will use Node.js 24.
Namely, this updates
- `actions/checkout`
- `actions/create-github-app-token` and
- `peter-evans/create-pull-request`
to their latest version which includes said updates. As for their most
recent versions, all of these actions just updated their versions to
account for said deprecation.
Release Notes:
- N/A
Closes#51339
This should address issues with too new libstdc++.so on older/more
conservative distros such as RHEL9.
Release Notes:
- Relaxed requirement for libstdc++.so available on Linux distros.
Reverts zed-industries/zed#48607
The problem we've ran into is that CI started reusing already-cached
runs from newer branches (that did not have that change pulled in).
Yet this unveiled another potential issue, which is that relying on
mtime might make it so that an artifact for a different (newer) commit
would be reused by an unrelated run of CI.
The answer is: checksum-based-freshness.
Release Notes:
- N/A
GitHub allows defining a default shell for all jobs on the workflow
level, which we did not use before, yet practically did when it comes
down to our usage of `named::bash`. Since this makes stuff quite
verbose, I decided on using the defaults instead so the workflows become
somewhat easier to audit when reading the generated files.
Powershell steps continue to use Powershell, only the default for bash
scripts was modified.
Release Notes:
- N/A
This reverts #39643, effectively
For the record, @SomeoneToIgnore found it quite cumbersome to scroll
through logs just to see which tests have failed. I kinda see the
argument. At the same time, I wish nextest could do both: it could
aggregate logs of failed tests and then print out the summary.
Release Notes:
- N/A
This starts the work on a workflow that can be invoked in extension CI
to test changes on extension repositories.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This hopefully resolves the lingering test failures on linux,
but also adds some logging just in case this isn't the problem...
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
One of the reasons we didn't spot that we were missing the telemetry env
vars for the production builds was that nightly (which was working) had
its own set of build steps. This re-uses those and pushes the env vars
down from the workflow to the job.
It also fixes nightly releases to upload all-in-one go so that all
platforms update in sync.
Closes#41655
Release Notes:
- N/A
Reverts zed-industries/zed#41384
The branch-protection rules work much better when there is a Job that
runs every time and can be depended on to pass, we no longer have this.
Release Notes:
- N/A
Follow up for: #41304
Splits CI tests (cherry-picks and PRs only for now) into separate
workflows using `gh-workflow`. Includes a couple restructures to
- run more things in parallel
- remove our previous shell script based checking to filter tests based
on files changed, instead using the builtin `paths:` workflow filters
Splitting the docs/style/rust tests & checks into separate workflows
means we lose the complete summary showing all the tests in one view,
but it's possible to re-add in the future if we go back to checking what
files changed ourselves or always run everything.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad <conrad@zed.dev>
To help make our GitHub Actions easier to understand, we're planning to
split the existing `ci.yml` into three separate workflows:
* run_bundling.yml (this PR)
* run_tests.yml
* make_release.yml
To avoid the duplication that this might otherwise cause, we're planning
to write the workflows with gh-workflow, and use rust instead of
encoding logic in YAML conditions.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Finn Evers