Skip to content
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

Pin Julia version #438

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

rikhuijzer
Copy link
Contributor

CompatHelper v2 doesn't work on Julia 1.8. This causes all workflow runs that are pinned to CompatHelper v2 to fail since the runners are allowed to use any Julia version (see also #437). To solve this problem in the future, this PR proposes to explicitly install Julia v1.8.

@DilumAluthge

@DilumAluthge
Copy link
Member

We set version = "3" when Pkg.adding CompatHelper; that should be sufficient to ensure that CompatHelper v3 is installed, right?

CompatHelper v2 is end-of-life, so we don't support it anymore.

@DilumAluthge
Copy link
Member

I think the combination of fixing the julia compat in the General registry (JuliaRegistries/General#67188) plus the version = "3" line (line 34 in https://github.com/JuliaRegistries/CompatHelper.jl/blob/master/.github/workflows/CompatHelper.yml) should be sufficient here, right?

run: |
import Pkg
name = "CompatHelper"
uuid = "aa819f21-2bde-4658-8897-bab36330d9b7"
version = "3"
Pkg.add(; name, uuid, version)

@rikhuijzer
Copy link
Contributor Author

rikhuijzer commented Aug 27, 2022

Changing 2 to 3 would be sufficient for all current setups yes. However, at this moment all CompatHelper setups pinned to v2 (CompatHelper.yml files) are broken and have to be manually updated to either go to CompatHelper v3 or to go back to Julia v1.7. The PR to the general registry doesn't solve that, right? I'm really bad at compat entries and the registry

This PR would avoid the problem for the future if it happens that v3 of CompatHelper is not compatible with, say, Julia 1.9.

The best solution would probably to add a new action julia-actions/compathelper which handles the Julia version and the communication with CompatHelper. Then it would be much less likely that some mass update for CompatHelper.yml-files is required.

@DilumAluthge
Copy link
Member

The best solution would probably to add a new action julia-actions/compathelper which handles the Julia version and the communication with CompatHelper. Then it would be much less likely that some mass update for CompatHelper.yml-files is required.

Yeah, I think that's going to be the best long-term solution. I've been working on it here: https://github.com/JuliaRegistries/compathelper-action

It still needs some more testing though.

@rikhuijzer
Copy link
Contributor Author

The best solution would probably to add a new action julia-actions/compathelper which handles the Julia version and the communication with CompatHelper. Then it would be much less likely that some mass update for CompatHelper.yml-files is required.

Yeah, I think that's going to be the best long-term solution. I've been working on it here: https://github.com/JuliaRegistries/compathelper-action

It still needs some more testing though.

Ah so I see that you're only one year ahead of me with having the idea 😆

I'll start using it and let you know if I run into trouble

@DilumAluthge
Copy link
Member

I don't think that https://github.com/JuliaRegistries/compathelper-action (in its current form) actually solves the issue you're bringing up here.

Right now, compathelper-action is a composite action. Composite actions can only have run steps - they can't call other actions (like the setup-julia action). So compathelper-action isn't actually able to call setup-julia to install the appropriate version of Julia.

I think we'd need to convert compathelper-action from a composite action to a reusable workflow, and then it would be able to setup-julia.

@DilumAluthge
Copy link
Member

@DilumAluthge
Copy link
Member

It looks like reusable workflows won't work on self-hosted runners.

So for people using GitHub-hosted runners (which is most people), they can use the reusable workflow (https://github.com/JuliaRegistries/compathelper-workflow).

But for those people that are using self-hosted runners, they'll have to use the composite action (https://github.com/JuliaRegistries/compathelper-action).

@rikhuijzer Would you be interested in testing out both options (the reusable workflow and the composite action)?

@rikhuijzer
Copy link
Contributor Author

Right now, compathelper-action is a composite action. Composite actions can only have run steps - they can't call other actions (like the setup-julia action). So compathelper-action isn't actually able to call setup-julia to install the appropriate version of Julia.

Are you sure about this? julia-actions/cache uses actions/cache (https://github.com/julia-actions/cache/blob/main/action.yml).

@rikhuijzer Would you be interested in testing out both options (the reusable workflow and the composite action)?

Okay. I'll do that. It will take a bit though because I'm on the road next week for work

@rikhuijzer
Copy link
Contributor Author

@rikhuijzer Would you be interested in testing out both options (the reusable workflow and the composite action)?

@DilumAluthge I've tested https://github.com/JuliaRegistries/compathelper-action manually and opened 2 PRs (JuliaRegistries/compathelper-action#24 and JuliaRegistries/compathelper-action#25).

The tests worked out fine for this Action. Would be nice if we could add some tests in CI, but without it things should also be okay given the relative simplicity of the setup. I'd say let's publish it and slowly move repositories over.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants