getsentry / .github Goto Github PK
View Code? Open in Web Editor NEWGlobal repo settings for sentry.io
Home Page: https://sentry.io
Global repo settings for sentry.io
Home Page: https://sentry.io
GitHub Actions
Issue is allowed, since there is a template with no headers.
Issue is not allowed.
Sentry Capacitor, using the latest version of Sentry Secrets on each run.
getsentry/sentry-capacitor#688
On this test PR, I added some secrets for testing the Secret Scanner integration, but it seems like it didn't fail nor trigger to anything (I also included the sample code used on the docs for triggering it).
A warning message or a failed action if secrets were found.
Test passed
Run if [ -e .secret_scan_ignore ]; then
π·ππ· TruffleHog. Unearth your secrets. π·ππ·
2024-07-10T15:34:44Z info-0 trufflehog running source {"source_manager_worker_id": "3aoRY", "with_units": true}
2024-07-10T15:34:44Z info-0 trufflehog scanning repo {"source_manager_worker_id": "3aoRY", "unit": ".", "unit_kind": "dir", "repo": "https://github.com/getsentry/sentry-capacitor"}
2024-07-10T15:34:44Z info-0 trufflehog finished scanning {"chunks": 737, "bytes": 2882128, "verified_secrets": 0, "unverified_secrets": 0, "scan_duration": "249.706709ms", "trufflehog_version": "3.79.0"}
This line now emits output when it didn't before, resulting in garbage like at getsentry/sentry#31735 (comment) (pre-edit).
I'm guessing the issue is caused by the fork but I'm honestly not sure why it's failing here!
Routing is currently a multi-click process:
Routing in the sentry and sentry-docs repos is done with Team: Foo labels and a comment mentioning @getsentry/team, with the "Team" field in the Registry being the source of truth for who owns what.
It could pretty easily be reduced to a single click: applying a Team label.
We are like 1990s PHP developers right now. We have no development pipeline, no tests, we're copying and pasting files all over the place, we're editing live on the server. How can we bring normal software development practices to this strange new serverless GHA world?
I want to store workflows in .github
and deploy from there out to target repos, in phases (i.e., onpremise
, then sentry-docs
, then sentry
, then ... ?). I envision an action here in .github
to do the deploy, with target_repo
as a parameter (probably required, with a special case of all
for GA deploy ... or maybe repo groups are defined in a yaml or something).
That's deploy. CI? I want to make a PR against this .github
repoβas I've done hereβand have CI kick in that runs the tests, but here's the catch: they need to run in a cleanroom repo, we don't want test fixture to clutter up this repo. I made a .github-ci
repo to use for that, but now I think we probably actually want to create repos on the fly so that multiple CI runs in parallel do not clobber each other. I envision an action here in .github
to do that, wired up like normal CI in any other repo (e.g.).
Okay! Deploy and CI! How about dev? I made a .github-chadwhitacre
repo for myself that has .github
as an upstream, so I can stay in sync and do my dev work off of the latest. The best way to develop GitHub Actions is by running them in a true GitHub Actions environment, that is to say, in the true actual cloud. βοΈ Trying to use nektos/act is going to be too heavy and drifty by comparison. π’ I made a helper script called ons
(for "on save" ... also considering gah
as a play on GitHub Actions and the exclamation "Gah!!") that commits, pushes, and kicks off test actions in my dev repo. I've been running it manually but it could maybe be hooked up to run on save in one's editor if so desired. My workflow is:
ons
Test actions are named foo-test.yml
(Γ la foo_test.go
).
Here's a wrinkle: I want to keep test yamls out of the main .github
repo, just like we don't ship test code to prod in other software architectures. Actually, nevermind: .github
is not the prod environment, it's the final step before prod. The action that deploys action yamls to the actual target repos will not ship test yamls. Done!
.github
.ons
.Validation bot is supposed to skip all getsentry org members, public or private. Seems to be whiffing on private members. Is the right API out there? Any hope for the flowers? Maybe give the bot more perms?
If we can't fix this, consider:
Would be great when looking at a Jira ticket that has a public GitHub shadow ticket, to see the GitHub engagement level (comments, reactions) at a glance in Jira (sidebar?).
Part of #8.
@BYK at getsentry/self-hosted#830 (comment):
we may want to make the issue validation bot a bit less aggressive. I think it tripped on the extra heading @/JeSappelleRoot added.
Example getsentry/sentry#23793.
Not sure how much we can do about this. Maybe we can ignore transferred issues if that information is available in the payload?
The Open Source Team is responsible for routing all incoming issues to the appropriate team, but we don't have a good queue to work against, which makes it hard to ensure that we're not missing issues. The general GitHub notification stream is waaaaay too noisy (regardless of how it's consumed: email, web, etc.).
Teach the validate-new-issue
action to apply a Status: Unrouted
label to issues that pass validation. With this label humans (for now) can use a search like this to stay on top of routing:
https://github.com/getsentry/onpremise/issues/837
Hi. I did use the template but added an additional headline. This or something else might have tripped the parser. I added "Feature Request: " to the title after the fact, wasn't sure if it was needed.
Thanks for taking a look!
If there's already a Status: *
label on an issue then the Team: *
action should not re-route.
E.g.
4 weeks is nothing
I'd go with 6 months :D
4 weeks seems aggressive - is that typical for a project like this?
I was thinking a few months
Eg it tagged a ticket of mine that was 2 years old - that makes sense
The only repos that are shared by multiple teams are sentry
and sentry-docs
. The vast majority of our repos belong to only one team, so any tickets opened there are already routed. They are not triaged, however, and we do want global visibility into triage, so we need to standardize the process across all repos.
When we route a ticket, find a way to send a Slack message.
We just turned on SSO for our GitHub org, need to audit bots and make sure they still work.
(just re-formatted to follow your template, please re-open the issue. Thanks)
For invalid issues we comment, but for valid issues we do nothing. Let's add a welcome message that gives us a chance to:
Reticketed from getsentry/open.sentry.io#1.
Reticketed from https://github.com/getsentry/.github/pull/21/files#r563331189.
Parent: #22.
.github
exempt-issue-labels
includes additional labels in order to fit in with existing triage workflows (cc: @bruno-garcia).We're closing too many issues as invalid. We have a bunch but I don't see another issue to track this already.
Latest: getsentry/sentry#24526
Auto close issues and PRs not adhering to the templates
Example: https://github.com/seferov/pr-lint-action
onpremise
\r
bug: #8 (comment)onpremise
sentry-docs
sentry
GHA test suite (run manually atm).
Test suite is consistently green.
Test suite is occasionally red with an error like this:
download-and-extract backed right off the edge!
and a mismatch in the expected and actual issue number in the downloaded log file.
We make an assumption that run_number
== issue_number - 1
(offset vs. ordinal), which holds most of the time. We make this assumption because there doesn't seem to be a way to request the logs for a workflow run based directly on the issue number for the issue event that triggered the run, and it's going to be less download-y to start with run_number
and radiate outwards in the list of all recent workflow runs than some other strategy (such as always starting with the most recent run and working backwards). The way I see to resolve this bug is to implement the radiating outwards.
This would make queries cleaner.
When an external user comments on an issue in Status: Needs More Information
, we should switch back to Status: Untriaged
.
There are already a few instances of people using LLMs to generate very long, detailed, and wrong solutions to peoples' raised bugs
getsentry/sentry-javascript#8285 (comment)
getsentry/sentry-javascript#8281 (comment)
It's not immediately obvious that those were generated by LLM (even though it's quite glaring in hindsight), and it's quite exhausting to respond in a way that don't hurt their feelings while still communicating to anyone else (mainly the maintainers) who might just be skimming through that the large blob of confident-looking hallucination-masquerading-as-a-solution is actually not a solution to the problem.
Thoughts on adding something to Code of Conduct that no responses should be generated via LLMs without proper disclaimers for the portions that are generated? And ideally also no LLM generated responses should be posted without the poster verifying that they really tried to understand both the originally posted problem and has done their best to verify the veracity of the generated text?
(prior art https://news.ycombinator.com/item?id=36178342)
Parent: #22
Not every repo needs to have its own issue templates defined. In fact, it's probably true that almost all of our repos should be using the global default templates. The issue validator bot/action as it stands today only checks new issues against templates defined in the local repo.
We should improve the issue validator bot to check local templates if they exist, and global templates otherwise.
The global issue templates in this repo aren't working because the implementation is weird and we need to nest them in .github
directory for them to work:
https://github.community/t/issue-template-for-organization-does-not-work/2049/17
h/t @bruno-garcia
From @jan-auer in DM:
I quite dislike the lag that GH actions come with for bots. A few examples:
- Our danger actions come with 20-30s delay of editing PR descriptions.
- The new stale bot doesn't immediately remove the label once there's activity (at least I haven't seen it do that).
Suggested solution is Probot.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.