create the infrastructure to use custom tic.R

[maelle]

related to many issues. It probably just means wrapping travis::use_tic() and then replacing the tic.R with our template(s).

• For packages, we want the regular package tic.R + coverage stuff that might be coveralls (so not included by default in the regular package tic.R) + covrpage + maybe project health Run project health stuff on Travis #81

• For analysis, we want a deploy step rendering all reports of a folder into output, deploying output to a branch. Cf Analysis: Add production scripts #5

[maelle]

Replace usethis::use_travis() with pieces of it only

• travis_enable()
• use_travis_yml() (unless we need a special one)
• copy our own custom tic.R depending on project type (for packages, copy pRojects setup)
• use_travis_deploy() except for basic projects, that'll get no deploy maybe? Or maybe they'll do?
• travis_set_pat()

[maelle]

and do all of this if the session is interactive, do nothing and message if not.

[maelle]

it'd be good to have the information on what type of project the project is without having to pass that as an argument. Maybe each function creating a project could

• create a file .project_function at the beginning and in it would be the function name
• delete it at the end
  this way one could keep not having the path/project type to setup_repo()

[maelle]

Maybe basic projects don't need any Travis stuff 🤔 Of course they could use the project health report, but not sure it's useful.

• packages: check, deploy docs website, covrpage report, deploy project health report.
• training: deploy the material on a branch, maybe project health report.
• analysis: deploy the output on a branch, maybe project health report.

[stephlocke]

sure, that works