-
Notifications
You must be signed in to change notification settings - Fork 668
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
chore: try GitHub Action #2166
chore: try GitHub Action #2166
Conversation
Well, no idea why GHA is not running with this PR, |
I've found something that sounds interesting: https://github.com/cirruslabs/cirrus-cli/blob/master/INSTALL.md#github-actions If I understand this correctly, the Cirrus CLI allows tasks configured for Cirrus to be run in other CIs, including GHA |
This is cool, just installed Cirrus CLI on my host, it can execute a specific task, which means if we separate the jobs that should be migrated to GHA into new tasks, then everything should just work? |
I hope so, that would be very nice. I'll play around a bit on my fork too and keep you updated |
Thanks! I just migrated 33 tasks to GitHub Action:
leaving the following tasks on Cirrus
You can preview it here Both ways are acceptable if they work! |
I've looked into GHA + Cirrus CLI, and I believe the primary usecases for that CLI are
I didn't find a way to tell Cirrus to skip certain tasks that get handled by GHA, other than setting up a persistent worker in GHA, letting it fetch and execute some tasks from the Cirrus Cloud and stopping it afterwards. I think a separate configuration for GHA is by far the better option. Edit: I got it working ... at least a little bit. I marked the tasks that should run on GHA as manual, and called them explicitly in the GHA workflow. I ended up with
No idea why this fails, and it's probably not worth the effort to get this working, so I suggest we should just use your approach |
Thanks for taking the time to investigate this tool! |
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 checked out your workflow files on my fork. These are the changes I needed to implement to make the CI pass.
You're welcome, I'm mind blown as well. And I've double-checked: no quotas, no fees, no limits, completely free (at least for me as a personal account, but I remember reading that this applies to all open-source projects) |
Optional, but we could allow GHA to check all branches, by setting on:
pull_request:
types: [opened, synchronize, reopened]
push:
branches:
- '*' Not required for the nix repository though, but this would allow forks to use the CI on other branches as well |
Yeah, this is a nice feature, our contributors can self-check their patches on the fork's CI with this |
Friendly ping @asomers, could I suggest giving this PR a review when you have time, so that we can handle other PRs without running out of Cirrus credits |
Sorry I've been taking a while, but I think I'll be able to do it this
weekend.
…On Mon, Oct 16, 2023, 9:29 PM SteveLauC ***@***.***> wrote:
Friendly ping @asomers <https://github.com/asomers>, could I suggest
giving this PR a review when you have time, so that we can handle other PRs
without running out of Cirrus credits
—
Reply to this email directly, view it on GitHub
<#2166 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA7VOOAGWFHVNOAU7ABXOTX7X3QBAVCNFSM6AAAAAA5XKNJEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGYYDMMBVGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Let me remove the migrated tasks in our Cirrus CI so that we can finally merge this PR We have a macro Lines 54 to 62 in b28132b
It is only defined under Android and Linux, given that we have Linux tests on both Cirrus (Linux/arm64) and GHA, we should probably provide the following macros as well, and document them in
#[cfg(any(target_os = "linux", target_os = "android"))]
#[macro_export]
macro_rules! skip_if_gha {
($reason:expr) => {
if std::env::var_os("GITHUB_ACTIONS").is_some() {
skip!("{}", $reason);
}
};
}
#[cfg(any(target_os = "linux", target_os = "android"))]
#[macro_export]
macro_rules! skip_if_ci {
($reason:expr) => {
if std::env::var_os("GITHUB_ACTIONS").is_some() || std::env::var_os("CIRRUS_CI").is_some() {
skip!("{}", $reason);
}
};
} |
@SteveLauC do you know why GHA isn't running? I don't see anything in the repository settings that we would have to enable. |
I actually have the same question:
One guess is that when I originally created this PR, I added |
It should work out of the box when the workflow files appear on the main branch |
@SteveLauC how about we revert the .cirrus.yml changes and merge this PR. Hopefully both CI engines will run then, and we can reapply the .cirrus.yml changes in a second PR. |
Yeah, this makes sense, just discarded my last commit |
What does this PR do
Our first try with GHA
This PR migrates our:
to two custom GitHub composite actions, and uses them on
x86_64-apple-darwin
Update: 33 tasks (we have 35 in total) have been migrated, see my last comment
Checklist:
CONTRIBUTING.md