-
Notifications
You must be signed in to change notification settings - Fork 11
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
Migrate to common GitHub Actions #21
Conversation
ec25981
to
182f228
Compare
182f228
to
565b944
Compare
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.
Thanks for doing this @rnro – this is mostly great!
@@ -1,5 +1,4 @@ | |||
|
|||
// Copyright 2015 gRPC authors. | |||
// Copyright 2015, gRPC Authors All rights reserved. |
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 proto files comes from upstream repos (some can be updated via a script) so we shouldn't modify their copyright headers.
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.
I've backed out the changes and added the any .proto
file under ./dev/protos/
to the ignore list.
scripts/build-performance-tests.sh
Outdated
@@ -0,0 +1,30 @@ | |||
#!/bin/bash |
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.
Can the scripts go back into dev
, please?
Originally we had both, but scripts ended up in dev
and ultimately they're only used by the developers of the project anyway so dev
felt more appropriate. The other benefit to just having dev
is that it's a little tidier at the top-level.
@@ -0,0 +1,18 @@ | |||
name: PR label |
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.
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.
No worries, no need for it to be unique, they can be uniquely referenced using the yaml file if needed. The listing now looks like this:
Stage Job ID Job name Workflow name Workflow file Events
0 unit-tests Unit Tests Main main.yml push,schedule
0 integration-tests Integration Tests Main main.yml schedule,push
0 swift-license-check Swift License Header Check PR pull_request.yml pull_request
0 unit-tests Unit Tests PR pull_request.yml pull_request
0 integration-tests Integration Tests PR pull_request.yml pull_request
0 cxx-interop Cxx Interop PR pull_request.yml pull_request
0 soundness Soundness PR pull_request.yml pull_request
0 semver-label-check Semantic Version Label Check PR pull_request_label.yml pull_request
e7241b5
to
fde134e
Compare
Migrate CI to use swiftlang / SwiftNIO common GitHub Actions. Motivation: * Reduce duplication * Centralise boilerplate changes when new Swift versions are picked up. * Benefit from centralised work to add new linting / test infrastructure. Modifications: Changes of note: * Use soundness checks from swiftlang/github-workflows. * Retain bespoke license-checking code for .swift files as the gRPC header style is very different to most templates. * Remove scripts which are no longer needed. * Move scripts to `scripts/` directory in-line with most other Swift on Server repositories. Result: More test, linting, formatting coverage. More common CI with other Swift on Server projects.
fde134e
to
a7cfe35
Compare
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.
Awesome, thanks @rnro
Migrate CI to use swiftlang / SwiftNIO common GitHub Actions.
Motivation:
infrastructure.
Modifications:
Changes of note:
header style is very different to most templates.
scripts/
directory in-line with most other Swift onServer repositories.
Result:
More test, linting, formatting coverage. More common CI with other Swift
on Server projects.