chore(IDX): move some tests to self-hosted runners

[cgundy]

Motivation

Now that we have moved the ic repo to github, we need to be more careful about using github-hosted runners so we don't run out of minutes for critical workflows. This PR moves several jobs that have shown up as consuming high volumes of minutes to self-hosted runners.

Changes

Use self-hosted runners with a container image we maintain. No code changes required.

Tests

All tests passed.

Todos

• Team can move over other long-running tests if necessary.

[daniel-wong-dfinity-org]

My understanding of this is low (therefore, no approve). However, FWIW, AFAICT, LGTM.

AFAICT, the main thing this does is change where things get run, but the new place has a very similar platform, resulting in almost identical behavior/results.

The other substantive thing I see going on here is

rustup default stable

Not sure why this is needed. I guess changing where things run implicitly changes the default toolchain away from stable (one of the small platform differences). Therefore, I guess this is needed to preserve stable, yes?

[cgundy]

rustup default stable

Not sure why this is needed. I guess changing where things run implicitly changes the default toolchain away from stable (one of the small platform differences). Therefore, I guess this is needed to preserve stable, yes?

Hey thanks for your input. I don't use Rust, so I am not familiar with the best setup. I added this step because I got the following error (workflow run)

error: rustup could not choose a version of cargo to run, because one wasn't specified explicitly, and no default is configured.
help: run 'rustup default stable' to download the latest stable release of Rust and set it as your default toolchain.

I'm open to any other suggestions!

[dskloetd]

I'm not too familiar with Rust either but it was my understanding that https://github.com/dfinity/nns-dapp/blob/main/rust-toolchain.toml defines the version to use.
If not, why is rustup default stable not needed on the GitHub runner and would it be possible to make the self-hosted runner be/do the same as the GitHub runner in this regard?

[cgundy]

I'm not too familiar with Rust either but it was my understanding that https://github.com/dfinity/nns-dapp/blob/main/rust-toolchain.toml defines the version to use.

We can - do you have an example from another part of the codebase for how it consumes the correct version?

If not, why is rustup default stable not needed on the GitHub runner and would it be possible to make the self-hosted runner be/do the same as the GitHub runner in this regard?

You can see here the rust version that was pre-installed on ubuntu-20.04 https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2004-Readme.md#rust-tools so it might be better practice anyways to use the same version as specified in this repo.

[dskloetd]

We can - do you have an example from another part of the codebase for how it consumes the correct version?

I'm not sure I understand the question but that file is regularly updated to increase the version and sometimes that results in new lint errors requiring changes. So changing that version definitely has some effect. See for example #5243

Also, if I run cargo --version inside the repo directory, it returns the version specified in rust-toolchain.toml, even if I change it.

You can see here the rust version that was pre-installed on ubuntu-20.04 https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2004-Readme.md#rust-tools so it might be better practice anyways to use the same version as specified in this repo.

Yes, we should be using the Rust version specified in rust-toolchain.toml. Are you saying we aren't or that we weren't or that we wouldn't be if we did or didn't do something?

[cgundy]

I think I found the issue - cargo needed to be run from inside the working directory to use the version in rust-toolchain.toml

Yes, we should be using the Rust version specified in rust-toolchain.toml. Are you saying we aren't or that we weren't or that we wouldn't be if we did or didn't do something?

Based on my understanding, it looks like you were using the cargo version specified in ubuntu-20.04 which luckily happened to be the same one. ;)

[dskloetd]

I don't think we were being lucky, because as I said, PRs that changed the version in rust-toolchain.toml would result in lint errors on CI.
And we don't currently reference GITHUB_WORKSPACE anywhere in the repo.
In my experience, after the checkout action, commands are run inside the repo.

But on line 50 of .github/workflows/checks.yml, I see cd / so that might be why there is no rust version in that particular case.
Maybe we can just remove line 50?
Or if it's needed, can we use pushd and popd?

Also since we're not actually building our wasm (only spellcheck), we don't really care what version of Rust we're using. Isn't it reasonable to have some default specified on the custom runner, similar to GitHub runners? I think in general for easier migration you might want to have your custom runners as similar as possible to GitHub runners.

[cgundy]

But on line 50 of .github/workflows/checks.yml, I see cd / so that might be why there is no rust version in that particular case.
Maybe we can just remove line 50?
Or if it's needed, can we use pushd and popd?

Ultimately your team owns the repo and the CI, so you can decide the best implementation. It looks like you were maybe using cd / so you could run the apt-install commands, so that might still be required. Adding GITHUB_WORKSPACE would solve the problem of running the job in the workspace and correctly using rust-toolchain.toml. Your lint job worked because it did not have this additional cd / step so it was already running in the correct working directory.

Isn't it reasonable to have some default specified on the custom runner, similar to GitHub runners?

Currently no, because different repos could require different versions and we're not in a spot where we can maintain different images with different versions yet.

[dskloetd]

I prepared a PR to remove the cd / command.
#5280
Once that's merged, the problem should be gone.

[dskloetd]

Isn't it reasonable to have some default specified on the custom runner, similar to GitHub runners?

Currently no, because different repos could require different versions and we're not in a spot where we can maintain different images with different versions yet.

I don't follow this. GitHub runners also don't maintain different images for different versions of Cargo. I'm not saying we should select the Cargo version via the image. I'm just saying that it might be easier to migrate (other jobs and other repos) if DFINITY runners are more similar to GitHub runners.