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

Print a danger warning when modified services are not in the PR title #2545

Open
paulmelnikow opened this issue Dec 17, 2018 · 3 comments
Open
Labels
developer-experience Dev tooling, test framework, and CI

Comments

@paulmelnikow
Copy link
Member

We already show a warning when services haven't been tested, though we don't compare that against the service names in the PR title. This should be pretty straightforward to do using the helper functions we have.

I'm not sure if Danger has access to the PR metadata, though we could generate it easily enough in an earlier step in the CI, using npm run test:services:pr:prepare.

@paulmelnikow paulmelnikow added the developer-experience Dev tooling, test framework, and CI label Dec 17, 2018
@platan
Copy link
Member

platan commented May 4, 2019

Maybe we should run service tests for all modified services? Was it discussed before? With this approach you will not need to add service name to PR title and this would be a very user friendly.

@chris48s
Copy link
Member

chris48s commented May 5, 2019

Maybe we should run service tests for all modified services? Was it discussed before?

Yes - #1936
I don't think any of the issues identified in that thread are impossible to solve, but there are definitely some tradeoffs to consider.

@paulmelnikow
Copy link
Member Author

One thing new since #1936 is that GitHub Actions have come online. I am not completely sure, though I think they provide a UI that lets users trigger actions. I'm not sure if you can set options for those actions. Might be worth an investigation, though! (Much easier than setting up Drone!)

Also along the original line of the issue, a danger warning is a nice place to start, because we can get a feel for how well the detection is working (false positives and false negatives) over a long period of time before we wire it up to the service-test run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Dev tooling, test framework, and CI
Projects
None yet
Development

No branches or pull requests

3 participants