r-hyperspec / pkg-skeleton Goto Github PK

SKELETON must not appear in the list of downloadable packages:

GHA workflows must take account into this.

I suggest leaving hySpc pattern for packages only and renaming other non-package repositories.

hySpc.skeleton sould be renamed into, e.g., pkg-skeleton.

In the skeleton's README, we could write a sequence of usethis or other (e.g., custom-made) commands, that help to set up the aspects of the package we do not know in advance. E.g., commands that add necessary badges, type of license, etc. There are functions that do the most of the job to set up Travis CI and Appveyor (this means that not only plain text files are created by those functions), etc.

I think the skeleton should contain only those elements of the package that work out of the box (E.g., GitHub Actions workflows, some examples of vignettes, and functions). And all the infrastructure should work in the skeleton: CI, code coverage, pkgdown builds, etc.

GH actions issues this warning:

Annotations

1 warning

Insert package (drat) : .github#L1

The ubuntu-16.04 environment is deprecated and will be removed on September 20, 2021. Migrate to ubuntu-latest instead. For more details see actions/runner-images#3287

We should update CI workflow in hySpc repos. There are some specifics in the main hyperSpec repo, so a separate issue will be opened there too.

@cbeleites provide me with write access to this repo. You may do it by providing write access to the whole @r-hyperspec/r-hyperspec team.

@GegznaV would you please look at .Rbuildignore on the develop branch and see if it looks OK? I ran a script which got .Rbuildignore from every repo and then grabbed all the unique values. I then manually went through it to organize. I dropped some entries that did not seem appropriate (really, the accumulated entries were a mess). If we do the best we can here, then when we actually deploy it we may still find some entries to add. I'm attaching the list of unique values for you to review.
Rbuildignore.txt

... to tell that we are slowly moving to MIT license.

R CMD check, e.g., https://github.com/r-hyperspec/pkg-skeleton/runs/4373275657?check_suite_focus=true runs into vignettes-related issue:

We should check if .Rbuildignore and other files with settings contain the correct setup.

Only after that vignettes-related file synchronization can be enabled. Synchronization of certain files across r-hyperspec repos was implemented in #21

• #21

Write CONTRIBUTING.md in a package-agnostic way so that it was possible to synchronize it across repositories in an automatic way.

Related:

• #21

There is a known issue related to the automatic distribution of files to several repos: the push from pkg-skeleton to other repos triggers GHA workflows on those repos, including drat workflow. The drat workflow tries to push updates to pkg-repo. But when updates from many packages are pushed at the same time, some workflows fail. See details here:

A manual restart of the failed drat workflow usually fixes the failure. But I think, we should find a way to disable triggering the drat workflow if the updates come from pkg-skeleton as these are usually setup files that update the infrastructure but do not change the functionality in the package.

Might help:

• https://github.community/t/how-to-stop-github-actions-workflow-to-trigger-when-the-pull-request-is-from-dependabot-preview/116486/2

This message in vignettes/.gitignore is missing:

# READ-ONLY FILE
#
# Original file resides in r-hyperspec/pkg-skelton.
# DO NOT EDIT in any other repo as these changes will be overwritten.
# Edit at r-hyperspec/pkg-skelton, then push there and
# this file will be deployed to the other repos.
#

Shouldn't this repo eoduniyi/hySpc.skeleton be transferred to r-hyperspec organization? Not as a fork but as the main repository. If @eoduniyi loses his rights for the repository, I think @cbeleites should grant @eoduniyi at least Write access.

... this is not strictly part of the skeleton package, but I think it would be good if we could have a consistent set of labels (including colors) for the derived packages and hyperSpec

• have the "master" set of labels here in the skeleton project
  for a start, copy the ones from hyperSpec
• make a code snippet/shell script that fetches them and pushes them into derived repository, see github API description

Use cron to run the R CMD check periodically on GHA. Currently, I think that automatic runs could be scheduled every 2 months.

@GegznaV would you please look at .gitignore on the develop branch and see if it looks OK? I ran a script which got .gitignore from every repo and then grabbed all the unique values. I then manually went through it to organize. I dropped some entries that did not seem appropriate (really, the accumulated entries were a mess). If we do the best we can here, then when we actually deploy it we may still find some entries to add. I'm attaching the list of unique values for you to review.
Gitignore.txt

The hyperSpec.skeleton will be a 'template' for several packages. Do we have a plan how we are going to synchronize them with each other?

I can imagine the following situation: we make four derived packages named A, B, C and D. Some time later, we decide to change the build system, or contrinuous integration, or vignette style, whatever. The purpose of the skeleton is to simplify this, so it should be possible to make a change only once in the skeleton package and propagate it to the derived packages.

Once we have this clarified, it should also go into the contributor's guide :)