chore(deps): bump webfactory/ssh-agent from 0.9.0 to 0.10.0 (#4910) Bumps [webfactory/ssh-agent](https://github.com/webfactory/ssh-agent) from 0.9.0 to 0.10.0. - [Release notes](https://github.com/webfactory/ssh-agent/releases) - [Changelog](https://github.com/webfactory/ssh-agent/blob/master/CHANGELOG.md) - [Commits](https://github.com/webfactory/ssh-agent/compare/v0.9.0...v0.10.0) --- updated-dependencies: - dependency-name: webfactory/ssh-agent dependency-version: 0.10.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> chore(deps): bump dessant/lock-threads from 5 to 6 (#4909) Bumps [dessant/lock-threads](https://github.com/dessant/lock-threads) from 5 to 6. - [Release notes](https://github.com/dessant/lock-threads/releases) - [Changelog](https://github.com/dessant/lock-threads/blob/main/CHANGELOG.md) - [Commits](https://github.com/dessant/lock-threads/compare/v5...v6) --- updated-dependencies: - dependency-name: dessant/lock-threads dependency-version: '6' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> feat: sync GitHub issue types with `type:` labels feat: enable manual backfill for issue labels This change introduces a `workflow_dispatch` triggered job that allows for manually re-evaluating and applying labels to existing issues. The new job iterates through a specified set of issues (filtered by state and an optional limit), adds a temporary `maintenance: relabel-backfill` label, and immediately removes it. The primary `labeling-issues` workflow is updated to specifically *not* ignore these bot-generated label events when the temporary label is involved, thus forcing a re-evaluation of the issue by the current labeling logic. This provides a mechanism to correct mislabeled issues or apply updated labeling rules to the entire issue backlog. feat: enhance relabel backfill with detailed summary and update github-script This change significantly improves the observability of the manual issue relabel backfill workflow by introducing: - Detailed console logging for each issue being processed. - A comprehensive `core.summary` output in the workflow run, providing tables for overall statistics, processed issues, and any encountered failures. Additionally, the `actions/github-script` action is updated to v8. chore: make issue type inference more robust by respecting existing labels Previously, the automated issue type inference relied solely on the issue title. This could result in valid `type:` labels being removed if the title was ambiguous or didn't explicitly match a predefined pattern. This change introduces a fallback mechanism where existing `type:` labels are considered if a type cannot be clearly inferred from the title. This reduces unnecessary label churn and improves the accuracy of automated labeling. fix: backfill runs triage inline instead of label-toggle GitHub does not fire new workflow runs when GITHUB_TOKEN creates label events (built-in loop prevention). Replace the label-toggle backfill approach with an inline version that mirrors the deterministic reconciliation logic from issue-ai-maintenance directly: type labels, command/distro labels, game/engine labels, Issue Type GraphQL sync, and tmux false-positive cleanup. No AI call is made during backfill. Also removes the now-unnecessary BACKFILL_TRIGGER_LABEL exemption from the bot-loop guard in issue-ai-maintenance. fix: track issue type + locked state in backfill summary - Add 'Issue Type set' column to processed issues summary table - Track issueTypeSet per issue (null when already correct/unchanged) - Skip REST label mutations for locked issues (they return 403) with a console note; Issue Type GraphQL sync still runs for locked issues - Show lock emoji in issue number column when issue is locked - Track actual applied add/remove counts (not desired counts) fix: allow backfill label updates on locked issues Remove locked-issue skip branch in backfill so label add/remove operations run for locked issues as well. Keep lock marker in summary for visibility. fix: keep legacy server request issues classified correctly Recognize 'server request' anywhere in issue titles (e.g. '[callofduty1] Server Request') and prefer type: game server request over generic feature when both labels exist. Apply this in both issue-ai-maintenance and backfill logic. fix: classify legacy server-request titles in backfill and maintenance Detect legacy server-request phrasing in issue titles: - bracketed game/server titles ending with 'Creation' - titles containing 'Server Creation' - titles containing 'Server Support' or 'Support for ... server' Apply the same heuristics in both issue-ai-maintenance and backfill inferTypeFromTitle paths so old issues are not downgraded to feature. feat: infer game labels from legacy issue text in relabel When no structured Game form section is present, infer game labels/scripts deterministically from title/body using serverlist alias mappings. Apply this to both issue-ai-maintenance and backfill to improve historical game labeling without relying on AI. feat: add optional AI fallback for backfill game detection Add workflow_dispatch input ai_game_fallback (default false). In backfill mode, only call AI when deterministic game mapping finds no match; accept only high-confidence results and map through known game aliases/labels. Include AI usage stats in the run summary table. fix: avoid pruning legacy game labels without structured game input Only remove existing game:* labels when an issue has explicit structured Game form selections. For legacy title/body inference (and AI fallback), add matched game labels but do not remove other existing game labels. This prevents edge cases like issue #1 from losing valid multi-game tags. fix: require alias evidence for AI game fallback labels Backfill AI game fallback now accepts a detected game only when the issue text contains a literal alias token for the mapped game label. Add explicit logs for AI accept/reject/unmapped outcomes to make attribution auditable in job logs and prevent false positives like issue #17. feat: annotate game label adds with detection source in backfill logs Each game label add now shows its source in the per-issue log line: #240: added "game: Opposing Force" (text-match) #248: added "game: Counter-Strike: Global Offensive" (form-field) #N: added "game: X" (ai-fallback) Non-game labels (engine, type, needs, etc.) are unchanged. fix: add missing hasAliasHitForLabel to backfill script context Each github-script step runs in its own isolated JS context. The backfill step was calling hasAliasHitForLabel (used by the AI alias-evidence gate) but the function was only defined in the triage step, causing a ReferenceError on any issue that triggered AI fallback. fix: retry AI fallback once on HTTP 429 with Retry-After backoff When the GitHub Models API rate-limits the backfill (429), read the Retry-After header (capped at 60s), wait, then retry the request once. If the retry also fails the issue is skipped as before. fix: accept joined-token alias evidence in AI game fallback gate Alias evidence now allows multi-token aliases to match when words are joined in issue text (e.g. counterstrike vs counter strike), while keeping exact token checks for single-word aliases. fix: treat generic AI detections as non-game in backfill When AI fallback returns generic platform/engine terms (e.g. srcds, source dedicated server, steamcmd), treat them as non-game detections instead of logging them as unmapped games. Also prompt the model to return null for generic terms. chore: log AI rate-limit headers and 429 count in backfill Capture Retry-After, X-RateLimit-* and request id on 429 responses, log them on retry and final skip, and include total AI 429 hits in the workflow summary table. fix: disable AI fallback for run on long Retry-After cooldown When GitHub Models returns 429 with a large Retry-After (over 300s), stop AI fallback for the remainder of the backfill run instead of sleeping and retrying per issue. Include disable reason in summary. fix: prevent overlapping game alias double-matches in text detection Prefer longest non-overlapping alias matches so titles like "Killing Floor 2" do not also infer "Killing Floor" unless both are explicitly present as separate mentions. fix: prune stale broad game labels when specific game is inferred For legacy issues without structured game selection, remove existing game labels only when they are broader overlaps of a newly inferred specific game label (e.g. remove Killing Floor when Killing Floor 2 is inferred). fix: stop relabel backfill early when API rate limit is hit Detect GitHub API rate limit errors during processing, stop the run gracefully, and report header-derived rate limit details in logs and summary instead of emitting repeated per-issue failures. feat(labeler): implement Linux support verification for server requests * Added checks for Linux support based on issue content and Steam API data. * Integrated AI analysis for documentation to assess Linux compatibility. * Automatically create or remove labels based on support verification results. * Enhanced feedback for users regarding Linux server support status. Co-authored-by: Copilot <copilot@github.com> fix(labeler): broaden Linux support check triggers for server requests fix(labeler): improve game detection logic for structured fields * Refine fallback logic to avoid guessing from free text when a structured Game field exists. * Ensure AI-detected game fallback only occurs when no structured Game field is present. Co-authored-by: Copilot <copilot@github.com> fix(labeler): update game section extraction logic * Adjusted the extraction of the game field to accommodate both 'Game server' and 'Game' sections. * This change improves compatibility with different input formats in server requests and bug reports. Co-authored-by: Copilot <copilot@github.com> feat(labeler): enhance Linux support detection logic * Added handling for dedicated server tool AppIDs in Steam API checks. * Introduced a checkbox confirmation mechanism for Linux support, improving evidence assessment. * Updated verdict messaging to clarify Linux support status based on new checks. Co-authored-by: Copilot <copilot@github.com> feat(labeler): implement SteamCMD Linux support check * Added a new function `runSteamCmdLinuxCheck` to assess Linux platform support using SteamCMD. * Enhanced existing logic to incorporate SteamCMD results alongside Steam API checks. * Updated comments to clarify the distinction between server tool AppIDs and client platform support. * Improved error handling and logging for SteamCMD assessments. Co-authored-by: Copilot <copilot@github.com> feat(labeler): add confirmed Linux support label logic * Introduced logic to determine and apply a `status: linux support confirmed` label based on AI assessment and Steam confirmation. * Implemented error handling for label creation if it does not exist. * Enhanced existing label management to ensure accurate representation of Linux support status. Co-authored-by: Copilot <copilot@github.com> fix(labeler): refine Steam support checks for dedicated servers * Updated comments to clarify the purpose of Steam Store API checks. * Removed unnecessary checks for Steam API results in determining Linux support. * Enhanced logging and reasoning for server tool AppIDs. * Improved clarity in the output messages regarding Linux support status. Co-authored-by: Copilot <copilot@github.com> feat(labeler): enhance Linux support check comment formatting * Added conditional header for Linux support check comments. * Included a block to indicate if the confirmed Linux label was applied. Co-authored-by: Copilot <copilot@github.com> fix: apply linux status labels directly instead of via deferred labelsToAdd set chore: synced file(s) with dgibbs64/repo-sync (#4911) * chore: synced local '.github/' with remote 'general/.github/' * chore: synced local './' with remote 'bash/' refactor: rename labeler.yml to issue-triage-automation.yml and consolidate sync-game-labels - Rename 'labeler.yml' to 'issue-triage-automation.yml' to better reflect the workflow's expanded responsibilities (issue triage, game detection, AI analysis, Linux support verification, and label syncing) - Consolidate 'sync-game-labels.yml' into the main workflow - Add push trigger for serverlist.csv changes - Add sync-game-labels job that runs on push events when serverlist.csv is modified - Remove the separate sync-game-labels.yml workflow This simplifies workflow organization by having all issue/PR maintenance logic in a single, well-named workflow. refactor: standardize workflow filenames with action prefix chore(sync): synced local '.github/' with remote 'general/.github/' (#4918) Synced from dgibbs64/repo-sync@732370ff26 — chore(workflow): add permissions section to action-sync.yml * Added an empty `permissions` section to the workflow file. * This change ensures that permissions are explicitly defined for the jobs.
8.5 KiB
Contributor Covenant Code of Conduct
Our Pledge
We pledge to make our community welcoming, safe, and equitable for all.
We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
Encouraged Behaviors
While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
- Respecting the purpose of our community, our activities, and our ways of gathering.
- Engaging kindly and honestly with others.
- Respecting different viewpoints and experiences.
- Taking responsibility for our actions and contributions.
- Gracefully giving and accepting constructive feedback.
- Committing to repairing harm when it occurs.
- Behaving in other ways that promote and sustain the well-being of our community.
Restricted Behaviors
We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
- Harassment. Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
- Character attacks. Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
- Stereotyping or discrimination. Characterizing anyone's personality or behavior on the basis of immutable identities or traits.
- Sexualization. Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
- Violating confidentiality. Sharing or acting on someone's personal or private information without their permission.
- Endangerment. Causing, encouraging, or threatening violence or other harm toward any person or group.
- Behaving in other ways that threaten the well-being of our community.
Other Restrictions
- Misleading identity. Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
- Failing to credit sources. Not properly crediting the sources of content you contribute.
- Promotional materials. Sharing marketing or other commercial content in a way that is outside the norms of the community.
- Irresponsible communication. Failing to responsibly present content which includes, links or describes any other restricted behaviors.
Reporting an Issue
Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.
When an incident does occur, it is important to report it promptly. To report a possible violation, please use one of the following methods:
- GitHub (private): Submit a private security advisory
- Discord: Contact a moderator via the LinuxGSM Discord server
Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.
Addressing and Repairing Harm
If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
-
Warning
- Event: A violation involving a single incident or series of incidents.
- Consequence: A private, written warning from the Community Moderators.
- Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
-
Temporarily Limited Activities
- Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
- Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
- Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
-
Temporary Suspension
- Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
- Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
- Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
-
Permanent Ban
- Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
- Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
- Repair: There is no possible repair in cases of this severity.
This enforcement ladder is intended as a guideline. It does not limit the ability of Community Moderators to use their discretion and judgment, in keeping with the best interests of our community.
Scope
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at https://www.contributor-covenant.org/version/3/0/.
Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/.
For answers to common questions about Contributor Covenant, see the FAQ at https://www.contributor-covenant.org/faq. Translations are provided at https://www.contributor-covenant.org/translations. Additional enforcement and community guideline resources can be found at https://www.contributor-covenant.org/resources. The enforcement ladder was inspired by the work of Mozilla's code of conduct team.