Beta testing of GitHub organization features

[Bisaloo]

The following repositories are enrolled in beta testing new GitHub organization-level features:

• cfr
• epidemics
• epiparameter
• episoap
• finalsize
• linelist
• quickfit
• scenarios
• simulist
• superspreading

Some recent examples are:

• new na_null_strings_linter() from etdev
• using merge groups to merge PR and streamline the automated commits generation
• the new dependency-change workflow

Please sign up below to enroll more repositories.

[pratikunterwegs]

Thanks, this looks interesting. I'll sign up {cfr}, {finalsize}, {epidemics}, and {scenarios}

[jamesmbaazam]

Is this a random set or are there criteria for enrolment? How do we enroll?

[pratikunterwegs]

Enter the packages you want these enabled for in the comments :)

[jamesmbaazam]

Thanks

[Bisaloo]

The "analyze dependency changes" workflow seems a bit too noisy to be useful at the moment. I'm afraid it's only teaching developers to ignore it. What do you think @joshwlambert @pratikunterwegs? Should it be disabled for now?

[joshwlambert]

I've not minded having the workflow run, I've found it helpful to point out system dependencies that are being taken on, but given the dependency graph of the packages are still changing it does not have the same prominence as if the package was stable. I don't mind whether it is kept or disabled (Hugo I see you're getting cc'd everytime it updates so if you're getting spammed I think it's best to disable for now).

[pratikunterwegs]

I would echo Josh - I'm a bit more aware of the system dependencies that are entrained now, and that's useful. Since we have a tendency towards minimising hard deps anyway, any additions flagged by the workflow are likely to be after some consideration, so pointing those out is less useful. I also echo Josh about cc-ing you in each run, that must be very spammy.

As an alternative, would it be more helpful to have this workflow triggered by GH releases, rather than every PR? Alternatively, on pushes (merges) to main?

[Bisaloo]

Thanks for the feedback. I have ended up importing this workflow to packagetemplate in epiverse-trace/packagetemplate#107 so that a conditional trigger on DESCRIPTION can safely be added.

This will prevent repeated duplicate messages in a single PR even if DESCRIPTION does not change in between commits.

I have now disabled the organization-level workflow. If you liked this workflow and want to keep it, please copy it from packagetemplate.

[pratikunterwegs]

Reporting an issue with the analyse dependencies workflow here as well: the workflow fails when the base branch is not an R package. This affects full package reviews for some older packages that were manually created before {packagetemplate} was adopted, as the review branch is compared against the first commit (which is often not a package). See e.g. this full package review in {cfr}.

We could change how we do full reviews by targeting the first commit after the repo was set up to be an R package, or by pulling the {packagetemplate} contents into a protected branch callled "empty", and having full reviews target that branch (with some wrangling around unrelated histories). Edit: I tried the second option (by changing the base on GH) but it led to the closing of the PR - in the interests of time I'll leave this experiment for later.