-
Notifications
You must be signed in to change notification settings - Fork 136
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: migrate ci setup from circle ci to github actions #464
Conversation
744787e
to
53ba34b
Compare
0ae4895
to
984399d
Compare
984399d
to
5df5d6f
Compare
var sigs []Signature | ||
var pubks []PublicKey | ||
for i := 0; i < size; i++ { | ||
msg := Message(fmt.Sprintf("cats cats cats cats %d %d %d dogs", i, i, i)) | ||
msgs = append(msgs, msg) |
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.
We're touching a test, is a typo or expected? I guess that breaks some linting rules?
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.
Yeah, the linting rules started failing. The issue made sense to me so I fixed it. I suspect we're using newer version of some linting tool or something like that.
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.
https://hub.docker.com/layers/cimg/go/1.21.2-node/images/sha256-59b3fff1c4745e9195ea35eef2cfbee4cb0b562616869e304b581644020ad4b8 - golangci-lint v1.54.2 vs v1.56.2
but, I don't see any version of golangci-lint failing on this file. staticcheck does but I don't see it being used here?
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.
btw I'm not objecting to this fix, just interested in why this is showing up for this diff
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.
This was the failing run before I added this change - https://github.com/filecoin-project/filecoin-ffi/actions/runs/9805936223/job/27076653921
It does come from staticcheck
as you pointed out. I wonder why we weren't running it in CircleCI.
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.
It is listed in the linters list there, too. Honestly, I'm not sure why it wasn't flagging this issue.
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.
make go-lint
only runs golangci-lint. So how about we add staticcheck install to this workflow and to the Makefile too so we have it properly covered
Needs investigation, golangci-lint is invoking staticcheck, I wonder if we need it installed for that to happen or if there's some config we're missing. Maybe we should just import the lotus config and be done with it. I'll try and get to figuring this out unless someone has a chance before me.
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.
It is running in GHA - that's why I had to add the fix - so I wonder how much time we want to spend investigating this.
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.
apparently golangci-lint has "staticcheck" but not quite the same as "staticcheck", so this is even more confusing ..
it's a good fix, so not a big deal, it would just be god to understand this and maybe fix our linting to do a better job
not a blocker for this PR
wget -q https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/sbsa/cuda-ubuntu2204.pin | ||
sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600 | ||
wget -q https://developer.download.nvidia.com/compute/cuda/12.5.1/local_installers/cuda-repo-ubuntu2204-12-5-local_12.5.1-555.42.06-1_arm64.deb | ||
sudo dpkg -i cuda-repo-ubuntu2204-12-5-local_12.5.1-555.42.06-1_arm64.deb | ||
sudo cp /var/cuda-repo-ubuntu2204-12-5-local/cuda-*-keyring.gpg /usr/share/keyrings/ | ||
sudo apt-get update | ||
sudo apt-get -y install cuda-toolkit-12-5 | ||
sudo mkdir -p /usr/lib/aarch64-linux-gnu/stubs |
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.
This is all new for GHA, is the arm64 image available to us different enough that there's no cuda available already?
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.
We're using an almost clean Ubuntu image for Linux arm64 self-hosted runners. We can add installing a version of cuda-toolkit in the machine image to the self-hosted runners backlog if you think it'd be good to have a default available on a machine. One question I have is how much we care about the version of the toolkit.
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'd like to hear @vmx on this; it's his area, cuda and nvidia driver versions for me are just a source of frustration rather than something I know a whole lot about!
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.
For development I recommend installing CUDA drivers from the NVIDIA website as the distro ones often don't work well (for whatever reason). Though for CI, I think using the distro packages could work (KISS). If it works for Linux, it should also work for ARM (I hope).
We should support old enough versions and for filecoin-ffi it's more of a sanity check. So whatever the CUDA version is, as long as the tests pass, we are good.
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.
Got it; I'd move on with installing it on linux arm during the run first, and once we add A version of it to the base image, we'll come back here and remove that step.
Looks pretty close to circle config. Not at all clearer though! I worry a little about future maintainability of complex GHA configs like this, but I'm not sure what can be done in lieu of a better config language for GHA. |
Co-authored-by: Rod Vagg <rod@vagg.org>
For the record, this closes #463 |
@vmx should be back this week and hopefully he can do a quick review on the relevant bits of this, particularly commenting on the cuda bits in the discussion above, and then we should be good to 🚢 |
sudo ln -s /usr/local/cuda-12.5/lib64/stubs/libcuda.so /usr/lib/aarch64-linux-gnu/stubs/libcuda.so.1 | ||
sudo ln -s /usr/local/cuda-12.5/lib64/stubs/libcuda.so /usr/lib/aarch64-linux-gnu/stubs/libcuda.so |
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'm not sure if that's really needed. It looks a bit like a direct port from the CircleCI config. I'd expect the files to be accessible through /usr/local/cuda/lib64/stubs/libcuda.so
(not that there's no specific cuda version in the path). And then later below, it should be enough to put the LD_LIBRARY_PATH
to usr/local/cuda/lib64/stubs/
(if that's needed at all, perhaps it's already found automatically).
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 tried the suggestion in #472, but it doesn't seem to cut it, unfortunately.
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 left comments, but generally it looks good and as long it's green I think it's good to be merged. Hence I'm approving it.
@galargh : anything blocking from getting this merged? |
Thanks for merging. I've now disabled CircleCI in this repo. Please ping me when you prepare to create a new tag here, we'll verify if publishing from GitHub Actions works as expected. |
#476 getting rid of circle config so it stops showing up in PRs; I assume this is the appropriate next step here.
Not sure how much we have queued that'll need it, maybe there's a new ref-fvm upgrade coming down the pipe but I don't think it's imminent. |
Of course we could just make a new tag, I don't think there'd be a problem with that now that we've got Lotus 1.28.0 done, a tag just for the sake of testing CI wouldn't be a bad thing I think. @rjan90 what do you think? |
Agree that we can just create a tag for testing CI, but let us schedule it after the Mainnet upgrade on |
In this PR, we migrate the CI from CircleCI to GitHub Actions.
The important difference in the GitHub Actions setup is that we're running the Linux ARM64 builds on self-hosted GitHub Actions runners.
Code style checks, builds, and tests have been tested in CI - see https://github.com/filecoin-project/filecoin-ffi/actions/runs/9857064865
Publishing will only be verified after the merge.
Before the merge, we have to stop building in CircleCI and change the Required workflows setting.
Once we verify the new workflow works as expected, we're going to remove the CircleCI configuration altogether.
As requested, the GitHub Actions release workflow supports releasing from an arbitrary historical refs using the workflow dispatch trigger with ref input.