-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option for adding a separate display name for repositories. #223
Conversation
Backwards compatibility summary:
|
@@ -1111,6 +1111,10 @@ type project_metadata = { | |||
?repo_id: string option; | |||
(* a.k.a repository owner id *) | |||
?org_id: string option; | |||
|
|||
(* Users can set a different name for display and for PR comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that I introduced a ci_config_from_cloud type in this file, that has a dirs_config: field
especially designed for monorepos, to allow to have different configuration per directory.
It's not used yet by the backend, but I think we should start using it, to become monorepo friendly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chmccreery I know your team has other priorities but I am pretty concerned that the env var method of configuring monorepos won't be ergonomic, which would still hamper adoption. Would love to sync on what we could or couldn't accomplish quickly with a cross-team project on monorepos.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we should go towards the ci_config_from_cloud data structure I defined above.
That way we get all the info from the cloud in a uniform way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(and typed way)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I am in no way wedded to env variables, though I think they are useful for allowing customization/overrides. If you wanted to auto-detect this variable for monorepos, that seems fine as well to me! Maybe I'm missing the context on what would be needed from the backend in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I agree we need to support multiple versions of the CLI, which is why martin actually implemented this tool, atddiff, that statically check breaking compatibility changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the CI would just run 'semgrep ci'
I'm not sure this is what users want. I'm not sure what they want (I haven't spoken to people about this) but I imagine that if your entire codebase is one monorepo you could want to let your teams run semgrep separately on each repo, the way we do for semgrep vs semgrep-app. Maybe worth speaking to Milan first to figure out the preferred use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other concern with one semgrep ci
run is that I'm worried it doesn't actually help us solve the main problem, which is CI timing out on long semgrep scans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This random github thread is getting long; @chmccreery do you have a preferred place to discuss something like this? Maybe an "RFC" ticket on Findings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe ... milan knows maybe better the actual use case. But anyway, I'd rather not (ab)use environment variables to store useful information; it's not typed, it's not explicit, it's fragile. I'd rather have actual fields in semgrep_output_v1.atd
make setup && make
to update the generated code after editing a.atd
file (TODO: have a CI check)For example, the Semgrep backend need to still be able to consume data generated
by Semgrep 1.17.0.
See https://atd.readthedocs.io/en/latest/atdgen-tutorial.html#smooth-protocol-upgrades