Skip to content
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

Sorald in CI: Dogfood SoraldBot, breaking the build #440

Closed
slarse opened this issue Mar 22, 2021 · 5 comments
Closed

Sorald in CI: Dogfood SoraldBot, breaking the build #440

slarse opened this issue Mar 22, 2021 · 5 comments

Comments

@slarse
Copy link
Collaborator

slarse commented Mar 22, 2021

We should setup SoraldBot for this repo, and have it always use the latest snapshot version (see #439)

@slarse slarse added this to the Week 13 milestone Mar 22, 2021
@monperrus
Copy link
Contributor

See #448

@slarse
Copy link
Collaborator Author

slarse commented Mar 26, 2021

On hold for now

@slarse slarse removed this from the Week 13 milestone Mar 26, 2021
@monperrus
Copy link
Contributor

monperrus commented Mar 30, 2021

Options:

  1. SonarQube instance breaks with warnings (can we specify a list of rules?) (in Spoon, sonarqube.ow2.org/, SonarCloud on Sorald)
  2. Sorald called via command-line in CI script breaks the build. Per our conversation, to break the build, we must be sure that the violation can actually be fixed, with a correct line identifier, and was actually introduced in the current PR.
  3. Maven-repair w/ sorald breaks the build, add support for "Sorald mode" in maven-repair eclipse-repairnator/repairnator#1197
  4. We develop a maven-sorald-plugin

@monperrus monperrus changed the title Dogfood SoraldBot Dogfood SoraldBot, breaking the build Mar 30, 2021
@slarse
Copy link
Collaborator Author

slarse commented Mar 30, 2021

So, there's a bit of a snag with SonarCloud. The secret required to run the SonarCloud analysis is not available to a pull request triggered from a fork. That's reasonable: we don't want untrusted users to have access to secrets with code with haven't vetted.

The problem then is how to actually activate the analysis. This blog post suggests a few alternatives. One pretty reasonable one is to allow a pull request from a fork access to secrets if it's labeled with a specific label, say safe, or something like that. Only repository collaborators are allowed to use labels, and so this would mean that code must be inspected before analysis runs.

Another alternative would be to run SonarCloud analysis on the main branch only, and use it reactively rather than proactively. We could then adopt the pragmatic approach of only breaking the build for issues that Sorald can fix. We could do something like this:

  • Run SonarCloud only on the main branch, use it to keep track of issues.
  • On pull requests, we do a simplified version of option 2: break the build if there's ANY violation that Sorald can fix.
    • As long as we make sure Sorald is clear of any violations it can repair, this will be equivalent to breaking the build for newly introduced violations.

Thoughts?

@monperrus monperrus changed the title Dogfood SoraldBot, breaking the build Sorald in CI: Dogfood SoraldBot, breaking the build Apr 13, 2021
@slarse
Copy link
Collaborator Author

slarse commented May 28, 2021

I think we can close this now as we have sorald-buildbreaker running on this repo.

@slarse slarse closed this as completed May 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants