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

Use eager Pkg server registry instead of git cloning #31

Merged
merged 2 commits into from
Mar 13, 2023

Conversation

fredrikekre
Copy link
Contributor

@fredrikekre fredrikekre commented Mar 13, 2023

Simpler alternative to #29 and #30. If one wants the conservative registry one can configure that by setting the environment variable globally intead. Will need a companion PR to julia-actions/runtests (julia-actions/julia-runtest#74)

@fredrikekre fredrikekre requested a review from a team as a code owner March 13, 2023 09:14
@fredrikekre fredrikekre force-pushed the fe/eager branch 3 times, most recently from cf7c329 to 2175b65 Compare March 13, 2023 09:31
@codecov
Copy link

codecov bot commented Mar 13, 2023

Codecov Report

Patch and project coverage have no change.

Comparison is base (252d468) 100.00% compared to head (46deeb4) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##            master       #31   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines            2         2           
=========================================
  Hits             2         2           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

This patch removes the git cloning of General and instead uses the eager
registry flavor. In addition, the action exits early if no deps/build.jl
file exist.
Copy link
Member

@SaschaMann SaschaMann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This does seem a lot simpler than the alternative PRs.

I don't know how the Pkg servers/registries work well enough to review this properly but the GHA parts look fine.

@SaschaMann SaschaMann merged commit fcafde1 into julia-actions:master Mar 13, 2023
@fredrikekre fredrikekre deleted the fe/eager branch March 13, 2023 11:21
@SaschaMann SaschaMann linked an issue Mar 13, 2023 that may be closed by this pull request
@DilumAluthge
Copy link
Member

This is not sufficient, which is why I was working on #30.

With this PR, here is what will happen. Suppose that the user does not set the JULIA_PKG_SERVER_REGISTRY_PREFERENCE environment variable in their GitHub workflow file.

  1. This action runs, which gives the user the eager reference.
  2. In a subsequent step, the user calls e.g. Pkg.add(), or some other registry operation that updates the registry. Because the JULIA_PKG_SERVER_REGISTRY_PREFERENCE environment variable is not set, Pkg will use the conservative registry. If the conservative registry is behind the eager registry, this means that Pkg will overwrite the eager registry with the conservative registry.

The point is, if you want to use the eager registry for a CI job, it's not sufficient to just set the environment variable for one step in the job. You have to make sure that the environment variable is set for ALL future steps in the job, because if a future step runs a Pkg operation, and the environment variable is not set, that Pkg operation will restore the conservative registry (overwriting the previous eager registry).

@fredrikekre
Copy link
Contributor Author

True. julia-actions/julia-runtest#74 does it for runtest so for the vast majority of packages things are OK already.

In any case, it doesn't hurt to export the env var unconditionally actually.

@DilumAluthge
Copy link
Member

In any case, it doesn't hurt to export the env var unconditionally actually.

Yes, which is what I was working on in #30 (exporting the environment variable by default, but having an option for the user to disable the environment variable propogation).

@SaschaMann
Copy link
Member

but having an option for the user to disable the environment variable propogation

We don't need an option for that, I think. They should be able to overwrite it by setting the env var in their workflows if for whatever reason they want to switch between the eager/conservative registry within the same workflow. Otherwise export whatever is being used here.

@fredrikekre
Copy link
Contributor Author

Agreed, it is better to tell the CI config what to do instead of what to not do. I will submit a PR.

@fredrikekre
Copy link
Contributor Author

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.

Reconsider using Pkg server by default for the registry
3 participants