-
Notifications
You must be signed in to change notification settings - Fork 67
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
Move CI to GitHub Actions #124
Conversation
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.
Neat!
The checkout@v2 action currently has a bug that makes it sometimes check out the wrong commit. Since we can't have that we'll use v1 for now, until that is fixed.
Thank you for working on this! I was thinking about doing this myself this week, but as we can see, you were faster! 👍
Does make sense, as we don't need to distribute any executable binary.
Hm, good question. We sacrifice a bit of coverage for
I would stick to stable, if we don't have any concrete reason to use nightly. I don't know any specifics about the
Fully agree. This is what I was going for in #96, with the intial goal to make the CI faster, but as travis showed, this attempt failed. Not in this case, though, and I am really excited about the results. |
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.
As I've said before, we are missing a build target at least for the examples with for at least one device (.e.g. stm32f303xc
) as it is used for clippy.
Do you expect linking to be an issue here? I'm worried that this will increase our CI times by a lot, since LLVM and linking is usually what takes the most time in a build. Other HAL crates I looked at also do
It does, when you specify the
You are right, there is no good reason to risk nightly here. |
If the other HALs only |
So I was just trying to implement this and actually stumbled upon one reason to run clippy on nightly after all: It simplifies the Check matrix quite a lot. Because if we don't run clippy on nightly, we should have another How about we leave the check matrix simple and clippy running on nightly and instead just make that clippy job a non-required one? This might be a good idea anyway, since clippy is also getting new lints on stable from time to time, so a stable update can make the job for a PR fail on entirely unrelated code. And if we have the clippy job non-required anyway, we can just use that same one for the nightly check too. |
That sounds good to me! |
Closes #113
The relevant functional changes to the Travis CI are:
We run
cargo check
now instead of a fullcargo build
. That still gives us all the error reporting and should be considerably faster.I added a clippy job too. That actually found a few code smells which I also fixed in this PR.
I have been debating if using clippy against the full MCU matrix would make sense (as an alternative to
cargo check
) but I figured that we'll find most issues with just thestm32f303xc
feature already.The job is using the nightly toolchain for the clippy check. This gives us the benefit of having all the latest and greatest lints, but might lead to FPs sometimes when new lints are not well tested yet. I'd be interested in your opinion on whether this is a good idea. If we do go back to stable here, we should add a nightly matrix entry to the
cargo check
job, so we still keep a nightly build in our CI.The different MCU features are now directly specified in the workflow YAML and not dynamically generated anymore.
This means we will have to touch the workflow config whenever we make changes to the supported MCUs, but we already need to touch two other files in this case anyway, so I don't think that's too bad. On the other hand, this simplifies the CI configuration as everything is in a single file now. Also we get more flexibility, in case we want to test more or fewer feature combinations in the future.
Performance was quite good in my tests . All jobs finished in under 1 minute and they run mostly in parallel, so the total time is not much higher. From looking at past PRs here, the Travis CI needed 5 to 6 minutes for a PR check.