-
Notifications
You must be signed in to change notification settings - Fork 39
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
Meta-issue: deploy the force_latest_compatible_version
fix to the most common CI providers
#298
Comments
I'm not sure who to ping for each CI provider, so I apologize in advance if I ping the wrong people. If I pinged you, but you are not a maintainer of the Julia plugin for the given CI provider, it would be great if you could ping the correct maintainers. For row 2 (GitHub Actions CI for users that do not use the For row 3 (Travis CI): @ararslan, @staticfloat, @StefanKarpinski For row 4 (AppVeyor CI): @simonbyrne For row 5 (Buildkite CI): @maleadt, @staticfloat For row 6 (GitLab CI), I'm not sure who to ping. I know that @mattBrzezinski and @fchorney are interested in GitLab; perhaps you can help me figure out who would be the best people to implement this feature for GitLab CI. |
force_latest_compatible_version
to the most common CI providersforce_latest_compatible_version
fix to the most common CI providers
Somehow I completely missed this before. For people that don't use that action, there's nothing we can really do about it. It's up to the people who write the workflow that runs the tests to set the appropriate flag in that case. |
Why do we only want to do this for automated PRs? Say CompatHelper makes a PR and tests fail with the newest version but fixing the tests requires minimal, backwards-compatible changes. If someone makes those changes in a separate PR, they might not be testing with the newest version because the |
I've had a crack at a very rough implementation of row 2 (ie GHA, but when not using the julia-runtest). I had a use case where I needed to run It's a simple and hacky approach (I am not very familiar with GHA, so it may not be the best approach). It borrows heavily from The draft action is here: github.com/angusmoore/julia-detect-dependabot and can be used with: The action has an output for if the branch is a compathelper/dependabot branch, which can be used by subsequent steps. The readme has an example. I do not know if this is the best/right way to solve this problem, but it worked for my use case, so others might find it useful too. |
As of Julia 1.7, the
Pkg.test
function now has the optionalforce_latest_compatible_version
keyword argument, which provides the solution to #160.However, in order to deploy the
force_latest_compatible_version
fix into production, we need to modify the various continuous integration (CI) platforms to support auto-detection of CompatHelper/Dependabot pull requests. Basically, we need to modify the CI configurations as follows:If the CI job is a pull request job, and the pull request was made by CompatHelper or Dependabot, then use the following
Pkg.test
command:If the CI job is not a pull request job, or if it is a pull request job but the pull request was not made by CompatHelper or Dependabot, then use the following
Pkg.test
command:Note that the
force_latest_compatible_version
keyword argument requires at least Julia 1.7. Therefore, for Julia versions prior to Julia 1.7, you should not provide theforce_latest_compatible_version
keyword argument.In julia-actions/julia-runtest#20, we implemented the auto-detection as follows. We look at the name of the branch from which the pull request was made, and:
compathelper/
ordependabot/julia
, we say that the current job is a CompatHelper/Dependabot job.This table tracks our progress:
julia-actions/julia-runtest
actionjulia-actions/julia-runtest
actionThe text was updated successfully, but these errors were encountered: