-
Notifications
You must be signed in to change notification settings - Fork 122
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
ci: Finish migration to Github Actions #604
Conversation
1533aed
to
62111dd
Compare
# Motivation I made more progress on the reusable workflows in NIO so it's even easier to adopt them. # Modification This PR fixes up the renamed workflow references and adds unit tests and cxx-interop checks. # Result Green GH actions CI
62111dd
to
cd74127
Compare
@simonjbeaumont @czechboy0 Would appreciate some eyes on the failing format check |
I suspect you want to add |
See here:
|
3352b91
to
3fbe65e
Compare
@FranzBusch It's still failing, seems the |
3fbe65e
to
d7a33ba
Compare
d7a33ba
to
c42ae5b
Compare
Ok, soundness is failing now:
I think it just requires you to add |
22c757e
to
2889fa0
Compare
@czechboy0 @simonjbeaumont This passes the format check now. Please take a look at the changes. I also added the integration tests and example tests here. Once we have this merged the only thing that is missing is
|
Just realised I have to change something in the reusable workflow to get the integration tests to pass |
a9d8e33
to
793e80b
Compare
@FranzBusch noticed this got reopened. Should I assume it's still a WIP for now and wait for a ping from you to review? |
793e80b
to
828b992
Compare
@simonjbeaumont @czechboy0 This PR is ready to review. The CI is all passing. I only had to skip the unacceptable language mode check and the shell check steps. I leave this up to you to re-enable them. The language mode depends on the old soundness CI to remove the text file with the words and the shell check depends on fixing up a few scripts. I would also encourage you to look into the examples CI and if you can reduce build times by using the same build dirs. You are currently rebuilding the same dependencies multiple times. |
The compatibility test is also missing but similarly to the above could you please set that up in a follow up. It would be a good exercise to see if the reusable workflows give you want you need. |
Looks broadly good to me, but I'll let @simonjbeaumont review more closely and sign off. |
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 all the work here @FranzBusch! Left some comments.
@simonjbeaumont Gentle ping. I think we can merge this. It should replicate everything that Jenkins is currently providing. |
I'll take this, this week. Sorry for letting it linger. |
0726458
to
a6efc31
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.
@FranzBusch this is now at a state where I'm happy with it.
I realise this was initially your PR, but could you take a look.
@czechboy0 once @FranzBusch and I are aligned. I think you should give it a look too :)
@FranzBusch I'm happy with this now and so is Honza. Can you do a final pass with your Github Actions hat on and then hit merge? :) |
linux_5_10_arguments_override: "--explicit-target-dependency-import-check error" |
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.
Should we track enabling warnings as errors for those pipelines at some point?
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.
More than happy to. But that's over-and-above what we currently had in this project. We can track it separately.
broken_symlink_check_enabled: true | ||
docs_check_enabled: true | ||
format_check_enabled: true | ||
license_header_check_enabled: true | ||
license_header_check_project_name: "SwiftOpenAPIGenerator" | ||
shell_check_enabled: true | ||
unacceptable_language_check_enabled: true |
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.
Why are we enabling them explicitly? The default is true
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.
Because it's more visible. The fact that some are default to true and some to false is confusing IMO. I like to be able to see what tests we're running in the YAML.
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 am fine with explicitly stating but just to be clear no check is defaulting to false
.
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.
OK, my mistake. Thanks for confirming :)
matrix_linux_command: "apt-get update -yq && apt-get install -yq jq && ./scripts/run-integration-test.sh" | ||
matrix_linux_5_8_enabled: false | ||
matrix_linux_nightly_main_enabled: false |
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.
Why not run them on the nightly main?
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.
Because it's materially slower and not blocking a PR. Note that this PR does use the nightly Swift versions in the scheduled workflow so we'll still be alerted. I'd really like to only have PR pipelines that are gating PR merges, especially when we have external contributors.
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 am surprised. Nightly main is slower than nightly 6.0? If so we should report that since this hints at a compiler speed regression.
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 no. It's slower because it's far less likely to have the image available.
What's really annoying (but I realise a Github Action limitation) is that this will still do a bunch of the warmup anyway because the if: false
is only at the step-level.
I have some ideas on how we can make that better though, if you're open to them.
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 have some ideas here as well. We could dynamically generate the matrix instead of having it hard coded like now.
matrix_linux_command: "./scripts/test-examples.sh" | ||
matrix_linux_5_8_enabled: false | ||
matrix_linux_nightly_main_enabled: false |
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.
Same here. Why not nightly?
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.
Answered above.
@@ -26,25 +26,25 @@ services: | |||
|
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.
Do you intend to keep the docker files around?
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 hadn't actually considered removing them altogether but I guess the only downside to doing so is that the existing CI will immediately fail because it can't find them. Maybe that's fine since we want it turned off anyway.
@czechboy0 any objections to me just deleting all the docker-based CI files?
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, let's get us moved over fully.
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.
Wait, I've realised that if we do this we'll be full of red X's on all PRs until we get them turned off because they'll still fire on the webhooks. Let's stage this in, get them turned off, then remove the files.
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.
You can turn off the web hooks yourself in the repo settings.
I can't approve since I am the author but LGTM! |
### Motivation In #604 we enabled all the Github Actions based workflows we need for CI. Since then we have updated the branch protection rules and disabled the webhook for the old CI, so we can remove the Docker Compose files that were used by the old CI. ### Modifications Delete the Docker Compose files. ### Result Less clutter in the repo. ### Test Plan This PR should show the new, Github Actions CI checks, and shouldn't be showing any of the older CI jobs. If that's true, we are safe to remove them.
Motivation
I made more progress on the reusable workflows in NIO so it's even easier to adopt them.
Modification
This PR fixes up the renamed workflow references and adds unit tests and cxx-interop checks.
Result
Green GH actions CI