juliaregistries / compathelper.jl Goto Github PK

https://github.com/JuliaImages/Images.jl/runs/317468145

Currently you have to write some slightly obscure Julia code to add custom registries before the bot does its main thing. Maybe registry cloning could be done less directly via configuration? For example:

env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  CUSTOM_REGISTRIES: A/B,C/D

It looks like we don't actually need the UUID and name of the registry, only the URL.

When updating it should go from

[Compat]
Example = "0.1"

to

[Compat]
Example = "0.1, 0.2"

and not as currently

[Compat]
Example = "0.2"

See mauro3/WhereTheWaterFlows.jl#2 (comment) where @fredrikekre pointed this out.

If you have this:

[compat]
PkgA = ">= 1”

CompatHelper doesn’t offer to fix this bad compat entry.

When a package repository tracks in test/Manifest.toml, docs/Manifest.toml, benchmark/Manifest.toml, etc., those files must be updated for the CI to run against newly available upstream packages. It would be great if CompatHelper.jl can automate this workflow as well. Is it in the scope of CompatHelper.jl?

Is there some way that a bot could actually also adjust the bounds in the registry for existing tagged versions, not just update the Project.toml in the package repo?

I am opening this issue to discuss what needs to be done in order for us to release CompatHelper version 1.0.

Is it possible to automatically label CompatHelper PRs with the no changelog label so that they don't fill up the TagBot changelog output?

It would be nice to be able to use some features of this package locally, on one's own computer, on demand.

Eg I could imagine something like

julia> import CompatHelper

julia> CompatHelper.show_possible_upgrades("~/code/to/my/repo")
# just list information, eg Foo could be upgraded 0.1.2 => 0.3
# do not modify files

julia> CompatHelper.propose_possible_upgrades("~/code/to/my/repo")
# when there are no uncommitted changes, modify files, otherwise abort

The user could then review and test these.

Looking at the sources, I think a lot of the building blocks for this are actually available.

thanks for this great package!

i open this issue because the docs are currently misleading as to when it runs: "Whenever one of your package's dependencies releases a new version...". i interpret this to mean that should one of your dependencies have CompatHelper installed, then it will notify you when a new version is released by posting a PR on your package. this of course would work well only if all packages had it installed. this interrupt style of working would be ideal as there would be less load on the servers and zero lag in the notification.

rather, i believe that CompatHelper polls a package's dependencies. the default is to do it every hour, as well as when issues are opened or re-opened. an okay workflow if an interrupt is not possible, but every hour seems way way way too excessive to me. i've changed mine to be every week. even running on every opened issue seems excessive. Registrator.jl, for example, only runs when an issue is opened with "@JuliaRegistrator register" in the comment text. could CompatHelper do that?

so four things i'd suggest:

1. change the wording of the documentation to more explicitly say your dependencies are polled for changes

2. consider implementing an interrupt whereby all packages that depend on your package are notified if you've bumped the version number.

3. change the default poll interval to be longer.

4. only run on opened issues which ask for CompatHelper to run.

thanks again for this package! huge step in the right direction.

Great bot! How can I modify the workflow to make CompatHelper check a custom registry besides General for dep version updates?

Thanks in advance!

I just want to run this on a package I have locally on disk without any PRs or GitHub usage etc.

It seems right now, the code mixes the logic for updating the project file with the GitHub features. It would be nice if those two features could be kept separate.

If you have this:

[compat]
julia = ">= 1”

CompatHelper doesn’t offer to fix this bad Julia entry.

I think CompatHelper should remove the branches once their PR is merged.
Similar to how https://github.com/marketplace/actions/create-pull-request does it.

It would be great if the commit message reflected which compat entry was changed, instead of
Automated commit by CompatHelper.jl from the branch
compathelper/new_version/2019-11-06-06-06-16-381-3275298043, the commit message would say the same thing as the pull request title.

For instance, when browsing the build log on travis, all I can see is the commit message and the brach name, so it's hard for me to relate to which entry a particular build is testing.

https://github.com/JuliaMusic/MusicXML.jl/commit/a8841bf8d2e994c51797f6f3e093ab1071c14395/checks

It would be helpful to create PRs when installing this Action to update the compat section to the latest and greatest. As it is (if I understand correctly), after installing I'll have to wait until a dependency updates until I get a PR.

Pkg.update fails if the manifest is tracking the unregistered version (add Upstream#master) and the upstream bump the version. It would be nice if CompatHelper checks the upstream git repositories if checked-in manifest files have the repo-url entry. Is it in the scope of CompatHelper?

I have added CompatHelper to my package, but it has sent me a lot of emails about it. Where's the problem?
https://github.com/JuliaMusic/MusicXML.jl/runs/291007366

Originally posted by @crstnbr in #103 (comment)

Hm. I obtain an error when using the suggestion above (CompatHelper.yml):

See the output here: https://github.com/crstnbr/TestPackage2.jl/commit/1d9350e3a0774841c3b2f1516430d358d5c3ab47/checks?check_suite_id=303953267

Error:

Run julia -e 'using CompatHelper, Pkg; CompatHelper.main(; registries = Pkg.Types.RegistrySpec[ Pkg.RegistrySpec( name = "General", uuid = "23338594-aafe-5451-b93e-139f81909106", url = "https://github.com/JuliaRegistries/General.git"), Pkg.RegistrySpec( name = "TrebstRegistry", uuid = "df7bba20-026d-11ea-1ecb-03517e44f23d", url = "https://github.com/crstnbr/TrebstRegistry.git") ] )'
Cloning into 'REPO'...
Already on 'master'
Your branch is up to date with 'origin/master'.
Cloning into 'General'...
ERROR: MethodError: no method matching iterate(::Pkg.Types.VersionSpec)
Closest candidates are:
  iterate(!Matched::Core.SimpleVector) at essentials.jl:604
  iterate(!Matched::Core.SimpleVector, !Matched::Any) at essentials.jl:604
  iterate(!Matched::ExponentialBackOff) at error.jl:214
  ...
Stacktrace:
 [1] in(::Nothing, ::Pkg.Types.VersionSpec) at ./operators.jl:1055
 [2] #make_pr_for_new_version#13(::GitHub.OAuth2, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::typeof(CompatHelper.make_pr_for_new_version), ::Function, ::GitHub.Repo, ::CompatHelper.Package, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/UyDZd/src/new_versions.jl:61
 [3] #make_pr_for_new_version at ./array.jl:0 [inlined]
 [4] #make_pr_for_new_version#12(::GitHub.OAuth2, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::typeof(CompatHelper.make_pr_for_new_version), ::Function, ::GitHub.Repo, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Set{CompatHelper.Package}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/UyDZd/src/new_versions.jl:21
 [5] #make_pr_for_new_version at ./array.jl:0 [inlined]
 [6] #main#1(::Array{Pkg.Types.RegistrySpec,1}, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::typeof(CompatHelper.main), ::Function, ::Base.EnvDict, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/UyDZd/src/main.jl:38
 [7] #main at ./none:0 [inlined] (repeats 4 times)
 [8] top-level scope at none:1
##[error]Process completed with exit code 1.

Did I do something wrong?

Dependabot has this feature, so we should probably add it too.

We will probably need to figure out version number bumping first (#132).

I have gotten a few mails with failed runs of compat helper, the log of one such failed event is here
https://github.com/baggepinnen/MonteCarloMeasurements.jl/runs/290182880

See also:

• bcbi/VersionVigilante.jl#10
• JuliaLang/Pkg.jl#1251 - "Feature request: Store multiple registered packages in a single Git repository"
• JuliaLang/Pkg.jl#1422 - "WIP add subdir functionality"
• JuliaRegistries/Registrator.jl#230 - "Allow registering packages in a subdir of the main repo directory"

Here it is JuliaFEM/MFrontInterface.jl#29

The problem relates to CxxWrap, because it goes hand in hand with libcxxwrap. When I use BinaryBuilder.jl approach the binaries are in the different repo (https://github.com/TeroFrondelius/mgisBuilder), which needs to be released first in order to be able to test new CxxWrap version. I hope my explanation makes sense. Anyway, this is the reason why I have fixed the CxxWrap = "= 0.8.1"

Maybe CompatHelper shouldn't make a pull request when compat pins exactly one version using "=" sign. What do you think?

Would it make sense to bump the version as well (but only when it is still at the version in the registry)?

I added this to a repo, Colors.jl, which turns out not to even have a [compat] section in the Project.toml. Here's the failure (I get an email about this once per hour, yikes!)

Already on 'master'
Your branch is up to date with 'origin/master'.
Switched to branch 'compathelper/new_version/2019-11-22-21-10-23-464-4982861'
ERROR: KeyError: key "compat" not found
Stacktrace:
 [1] getindex at ./dict.jl:477 [inlined]
 [2] #make_pr_for_new_version#14(::GitHub.OAuth2, ::Symbol, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::Array{Pkg.Types.RegistrySpec,1}, ::typeof(CompatHelper.make_pr_for_new_version), ::typeof(CompatHelper.update_manifests), ::String, ::String, ::GitHub.Repo, ::CompatHelper.Package, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/IcHji/src/new_versions.jl:256
 [3] (::getfield(CompatHelper, Symbol("#kw##make_pr_for_new_version")))(::NamedTuple{(:auth, :keep_or_drop, :parenthetical_in_pr_title, :master_branch, :pr_title_prefix, :registries),Tuple{GitHub.OAuth2,Symbol,Bool,CompatHelper.DefaultBranch,String,Array{Pkg.Types.RegistrySpec,1}}}, ::typeof(CompatHelper.make_pr_for_new_version), ::Function, ::String, ::String, ::GitHub.Repo, ::CompatHelper.Package, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at ./none:0
 [4] #make_pr_for_new_version#13(::GitHub.OAuth2, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::Array{Pkg.Types.RegistrySpec,1}, ::typeof(CompatHelper.make_pr_for_new_version), ::Function, ::GitHub.Repo, ::CompatHelper.Package, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/IcHji/src/new_versions.jl:81
 [5] #make_pr_for_new_version at ./int.jl:0 [inlined]
 [6] #make_pr_for_new_version#12(::GitHub.OAuth2, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::Array{Pkg.Types.RegistrySpec,1}, ::typeof(CompatHelper.make_pr_for_new_version), ::Function, ::GitHub.Repo, ::Dict{CompatHelper.Package,Union{Nothing, Pkg.Types.VersionSpec}}, ::Dict{CompatHelper.Package,Union{Nothing, String}}, ::Dict{CompatHelper.Package,Union{Nothing, VersionNumber}}, ::Set{CompatHelper.Package}, ::Array{GitHub.PullRequest,1}, ::Array{String,1}, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/IcHji/src/new_versions.jl:22
 [7] #make_pr_for_new_version at ./array.jl:0 [inlined]
 [8] #main#1(::Array{Pkg.Types.RegistrySpec,1}, ::Bool, ::Bool, ::CompatHelper.DefaultBranch, ::String, ::typeof(CompatHelper.main), ::Function, ::Base.EnvDict, ::CompatHelper.GitHubActions) at /home/runner/.julia/packages/CompatHelper/IcHji/src/main.jl:38
 [9] main at /home/runner/.julia/packages/CompatHelper/IcHji/src/main.jl:15 [inlined] (repeats 3 times)
 [10] top-level scope at none:1

would it make sense to check everything that's in "compat", not just the subset that's also listed in "deps"? the stuff in "extras" seems not to be checked. see GiovineItalia/Compose.jl#374

I wanted to install this on my repos, e.g., https://github.com/JuliaArrays/LazyArrays.jl but don't see an action tab

After I enable actions, I get a screen like this:

Then if I try adding a runner, I get a fairly dire warning:

This does not obviously match the description here.

Now that CompatHelper updates all Manifest.toml by default, it would be great if it looks at julia compatibility bounds in Project.toml and uses appropriate binaries to do this (or alternatively Pkg.jl takes julia bound into account while Pkg.update). ATM, it's very hard to support julia < 1.3 and >= 1.3 while making CI reproducible by checking in Manifest.toml file as many packages start dropping julia < 1.3 due to the new artifacts support.

I'm thinking to check in e.g. test/environments/jl10/Manifest.toml with julia = "< 1.3" in Project.toml so that I can still test it with Julia 1.0 via Run.test(project="test/environments/jl10"). However this requires test/environments/jl10/Manifest.toml to be updated with julia 1.0 while test/Manifest.toml to be updated with the latest julia.

I suppose this would require Julia installer as a Julia package (e.g., using JuliaLang/julia#33817) and/or distributing julia binaries as artifacts?

It might be useful to turn this into a "proper" action in addition to the Julia package/script that's run in the workflow. See julia-buildpkg for an example. Once set up, the action repo would not change if it just executes the commands that are currently called manually in the workflow, so while there's some initial overhead, it wouldn't require ongoing maintenance.

This could simplify the workflow to

    steps:
      - uses: julia-actions/setup-julia@latest
        with:
          version: ${{ matrix.julia-version }}
      - uses: bcbi/compat-helper-action@latest
        with:
          # config

and would allow you to publish it on the marketplace which could improve discoverability for people who don't follow the Julia community forums that closely. It may also be easier to set it up using the interactive workflow builder, but I haven't tried the new one out yet. People who prefer the current way would still be able to use it since the action would be a separate repo.

I'm not sure what UX people prefer in their workflows, just throwing it out there as a suggestion.

Consider this situation. Your Project.toml file looks like this:

[deps]
Foo = "uuid_for_foo_package"

[compat]
Foo = "2"

And your Manifest.toml file has Foo at version 2.0.0.

Now suppose that Foo releases version 2.0.1.

Your existing compat entry of Foo = "2" includes this new release 2.0.1. So CompatHelper will not make an PR to bump your compat entry for Foo. After all, you don't need to bump your compat entry for Foo.

But, since you made the decision to check your Manifest.toml into source control, perhaps you would like to update your Manifest.toml file so that it has Foo at version 2.0.1 instead of version 2.0.0?

I think we should have the option for CompatHelper to make a PR in these cases, so that you can keep your Manifest.toml files up-to-date even if your compat entries do not need to be bumped.

As with everything in CompatHelper, there will be a keyword argument that allows you to enable or disable this feature.

The question is: what should the default value be? Should this feature be enabled by default or disabled by default?

@christopher-dG @fredrikekre - Would love to get your input on this.

FYI, I noticed that I had to pass a custom token for GithHub Actions to work in the PRs created by CompatHelper.jl. See this PR tkf/BenchmarkCI.jl#27 before the commit configuring custom token and this one tkf/BenchmarkCI.jl#31 after. Maybe it is worth noting it in the manual?

I realized this when reading this note in the manual of create-pull-request action: https://github.com/peter-evans/create-pull-request#action-inputs

If you have a brand new package with no compat entries, CompatHelper will add the compat entries you need.

I should document this somewhere.

The tests will then still use the old version and not be effective in knowing if the package actually is compatible with the old version.

The problem is that the unresolvable project isn't the main Project.toml of the package, but rather is in a subdirectory, along with a Manifest pointing at the master version of a package (making it instantiate-able). It would be great to be able to use CompatHelper for the main Project.toml, but still have other environments in the repo giving the right branches etc for special situations.

Package with main environment: https://github.com/ericphanson/GuessworkQuantumSideInfo.jl

Failed CompatHelper run: https://github.com/ericphanson/GuessworkQuantumSideInfo.jl/runs/412677111?check_suite_focus=true

Special master-branch-using subenvironment: https://github.com/ericphanson/GuessworkQuantumSideInfo.jl/tree/master/test/high_precision_tests

Sorry if this is a duplicate! Didn't see anything already.