Git-Backed Content

RStudio Connect publishers can deploy content to Connect in a variety of ways. One mechanism is to create content on Connect directly from a Git repository. The user guide contains instructions on the steps taken by publishers.

Content deployed from a Git repository will be indicated both in the content listing with the text "from Git" and in the content's Settings -> Info with a Git-specific section containing metadata about the source repository.

Note

A given source repository may be associated with any number of applications.

Requirements

Note

Git >=1.7.12 is required for Git backed content.

The version of Git installed in the same environment as RStudio Connect is detected at process startup time, and is subject to the PATH set in the process environment. Alternatively, the path to the git executable may be set directly via Git.Executable.

If the version of Git cannot be detected, or if the version is lower than the minimum required of 1.7.12, an error will be logged and startup will be aborted. See Disabling to learn how to disable Git backed content support.

Publishing

Git backed content may be associated with either public or private Git repositories, and may use https:// (recommended) or http:// remotes.

The Applications.RunAs user will run all git commands necessary for retrieving repository data.

Note

Currently, RStudio Connect Git-backed publishing does not support Git Large File Storage (LFS).

Public repositories

Publicly-accessible source repositories may be configured by any user with a "publisher" role.

Private repositories

Private source repositories may be accessed by setting GitCredential.Host, GitCredential.Username, and GitCredential.Password, which will work with any authentication based on HTTP basic auth, such as with GitHub personal access tokens.

; /etc/rstudio-connect/rstudio-connect.gcfg
[GitCredential]
Host = github.com
Username = accountName
Password = <encrypted-string>
Protocol = https

Note

The encrypted string value of GitCredential.Password should be generated via rscadmin.

Automatic fetch & deploy

Git backed content differs from content that is directly published to RStudio Connect, as indirect user actions such as pushing a Git commit to the associated repository may result in a new deployment. The decision to trigger a new deployment is made after a periodic fetch of the source repository, and will only occur if the specified branch and path prefix have changed since the last fetched commit.

Note

Periodic Git fetches are automatically performed at ~15 minute intervals for each Git backed application. This interval duration may be modified via the Git.PollingFrequency setting. To turn off automatic Git fetches entirely you may set the value to 0.

Note

The same polling frequency interval and re-deployment logic are used for public and private repositories.

Operational considerations

Throughout the lifetime of managing Git backed content, various background processes may be spawned, and data written to file storage. As a result, the number and type of processes running on the system may vary independent of users interacting with RStudio Connect. The size and composition of file based storage may likewise independently change over time.

Repository data

All Git repository clones and cached metadata will be stored relative to the Server.DataDir at {Server.DataDir}/git.

Automatic cleanup

An automatic cleanup is triggered at startup time and periodically during runtime which is responsible for removing any Git repository data which is no longer in use. Such data includes Git repository clones which are not associated with content and temporary clones fetched prior to first deploy.

Concurrency limits

The Git.Concurrency setting limits the number of concurrent parent processes which may be spawned for Git operations. The limit is imposed at the individual Connect process level, meaning that a clustered deployment will have a total concurrency that is a multiple of the cluster members.

Process Management

Git operations are run in a process sandbox using the configured supervisor command, if any. It is particularly important to ensure that the supervisor command does not write anything to standard out, as this will interfere in unpredictable ways with git operations. Supervisor scripts must echo all informational messages to standard error rather than standard out.

Disabling

In the case that Git backed content is not desired, such as when the Git version requirement cannot be met, it may be disabled by setting Git.Enabled to false.