mirror of
https://github.com/GameServerManagers/LinuxGSM
synced 2026-08-18 20:23:04 -04:00
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.
159 lines
8.5 KiB
Markdown
159 lines
8.5 KiB
Markdown
# 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:
|
|
|
|
1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
|
|
2. Engaging **kindly and honestly** with others.
|
|
3. Respecting **different viewpoints** and experiences.
|
|
4. **Taking responsibility** for our actions and contributions.
|
|
5. Gracefully giving and accepting **constructive feedback**.
|
|
6. Committing to **repairing harm** when it occurs.
|
|
7. 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.
|
|
|
|
1. **Harassment.** Violating explicitly expressed boundaries or engaging in
|
|
unnecessary personal attention after any clear request to stop.
|
|
2. **Character attacks.** Making insulting, demeaning, or pejorative comments
|
|
directed at a community member or group of people.
|
|
3. **Stereotyping or discrimination.** Characterizing anyone's personality or
|
|
behavior on the basis of immutable identities or traits.
|
|
4. **Sexualization.** Behaving in a way that would generally be considered
|
|
inappropriately intimate in the context or purpose of the community.
|
|
5. **Violating confidentiality.** Sharing or acting on someone's personal or
|
|
private information without their permission.
|
|
6. **Endangerment.** Causing, encouraging, or threatening violence or other harm
|
|
toward any person or group.
|
|
7. Behaving in other ways that **threaten the well-being** of our community.
|
|
|
|
### Other Restrictions
|
|
|
|
1. **Misleading identity.** Impersonating someone else for any reason, or
|
|
pretending to be someone else to evade enforcement actions.
|
|
2. **Failing to credit sources.** Not properly crediting the sources of content
|
|
you contribute.
|
|
3. **Promotional materials.** Sharing marketing or other commercial content in a
|
|
way that is outside the norms of the community.
|
|
4. **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](https://github.com/GameServerManagers/LinuxGSM/security/advisories/new)
|
|
- **Discord:** Contact a moderator via the [LinuxGSM Discord server](https://linuxgsm.com/discord)
|
|
|
|
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.
|
|
|
|
1. **Warning**
|
|
1. Event: A violation involving a single incident or series of incidents.
|
|
2. Consequence: A private, written warning from the Community Moderators.
|
|
3. Repair: Examples of repair include a private written apology, acknowledgement
|
|
of responsibility, and seeking clarification on expectations.
|
|
|
|
2. **Temporarily Limited Activities**
|
|
1. Event: A repeated incidence of a violation that previously resulted in a
|
|
warning, or the first incidence of a more serious violation.
|
|
2. 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.
|
|
3. 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.
|
|
|
|
3. **Temporary Suspension**
|
|
1. Event: A pattern of repeated violation which the Community Moderators have
|
|
tried to address with warnings, or a single serious violation.
|
|
2. 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.
|
|
3. 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.
|
|
|
|
4. **Permanent Ban**
|
|
1. 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.
|
|
2. 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.
|
|
3. 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](https://github.com/mozilla/inclusion).
|