Sometimes github issues are created without following the template, and
if they don't receive the `state:needs triage` label from a template,
it's easy for us to miss them. Well, not anymore, thanks to this new
github workflow.
As an extra measure, the label is also added on reopened issues. All of
this only applies only to actions carried out by people outside of the
staff team.
Release Notes:
- N/A
Remove the attempts to have these issues land in the same 'inbox' (the
existing project board for triage). Since they're closed, the automated
workflow of the project board will move them to the 'Closed'
column/status even with the API call specifically moving them to
'Incoming' instead. It is what it is, we'll have a separate project
board for this.
Also:
- don't look at comments on PRs
- don't freak out if the issue has no type
- add a permissions block as a defensive measure (in case someone adds
secrets.GITHUB_TOKEN later)
- add a timeout to avoid hanging out for six hours or whatever the
default is
- add some logging.
Release Notes:
- N/A
Since the project board to which the closed bugs with new comments are
added might have an automated workflow for moving closed issues to the
"Done" status, we need to override the status to ensure the bugs are
actually surfaced to the team and not buried in "Done".
Release Notes:
- N/A
Sometimes bugs come back or are not fixed all the way. We want to
preserve the context of the issue we've closed prematurely so instead of
always making people open a new github issue in this case we want to be
able to notice if someone* comments on a closed bug and decide what to
do about it.
Before:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → Maybe someone sees the notification about it, maybe
not; maybe they see it but forget to act on it right away and it's lost.
After:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → The issue is added to a project board where it's
visible until someone makes a call about it (maybe the comment was “oh
my glob i'm so happy this was fixed” and no action is needed, or maybe
the issue must be reopened as a regression).
*Someone in this case means (1) not a bot, (2) not a member of staff.
Release Notes:
- N/A
This PR updates the `bump_patch_version.yml` to also be generated by
`cargo xtask workflows` and updates this to use the `zed-zippy` identity
instead of the `ConradIrwin` identity.
Release Notes:
- N/A
Updates the community champions list to the latest state, adding some of
our active extension contributors, and sorts the list/removes
duplicates.
Release Notes:
- N/A
I changed the runner sizes to a smaller but more recent image yesterday
and broke the version bumping in the process. This PR fixes this by
force installing the needed package.
Release Notes:
- N/A
GitHub flags these as security vulnerabilities. Hence, this PR specifies
the needed permissions for the workflows used in the `zed-extensions`
organization.
Release Notes:
- N/A
We adjusted the labels some time ago, but never took care of the `good
first issue` notifier that posts the good first issues to discord.
Adjusting the label accordingly so that it notifies people again.
Release Notes:
- N/A
`2x4` is not nearly enough for some of the grammars in use, hence change
this to a larger runner.
Also, reduce the size for the Rust runners a bit, as they don't need to
be quite as large for the amount of Rust code we have in extensions.
Release Notes:
- N/A
Stashes local changes before branch checkout in droid auto docs CLI
Release Notes:
- N/A
---------
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Droid needs a specific model with a date
Release Notes:
- N/A
---------
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Change from cli.factory.ai/install.sh to app.factory.ai/cli per official
Factory documentation.
Release Notes:
- N/A
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
Adds a multi-step agentic loop to github actions for opening a
once-daily documentation PR that can be merged only be a Zedi
Release Notes:
- N/A
---------
Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
- adjust wording for the upcoming simplified process
- upgrade to the github action version that has a fix for configuring issue types the bot should look at
- add two inputs for the manual runs of stalebot that help testing it in a safe and controlled manner
Release Notes:
- N/A
Closes #ISSUE
Uses the existing `--dump-all-actions` arg on the Zed binary to generate
an asset of all of our actions so that the `docs_preprocessor` can
injest it, rather than depending on the Zed crate itself to collect all
action names
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
I think we're not triggering the after-release workflow because of
github's loop detection when you use the default GITHUB_TOKEN
Closes #ISSUE
Release Notes:
- N/A
Split running `cargo clippy` out of the job that has access to ZIPPY
secrets as
a precaution against accidentally leaking the secrets through build.rs
or
something...
Release Notes:
- N/A
One of the major annoyances with writing code with claude is that its
poorly indented; instead of requiring manual intervention, let's just
fix that in CI.
Similar to https://autofix.ci, but as we already have a github app,
we can do it without relying on a 3rd party.
This PR doesn't trigger the workflow (we need a separate change in Zippy
to do
that) but will let me test it manually.
Release Notes:
- N/A
