Posit 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.
A given source repository may be associated with any number of applications.
>=1.7.12 is required for Git backed content.
The version of Git installed in the same environment as Posit 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
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
Git backed content may be associated with either public or private Git
repositories, and may use
https:// (recommended) or
user will run all
git commands necessary for retrieving repository data.
Currently, Posit Connect Git-backed publishing does not support Git Large File Storage (LFS).
Publicly-accessible source repositories may be configured by any user with a "publisher" role.
Private source repositories may be accessed by setting
which will work with any authentication based on HTTP basic auth, such as with
GitHub personal access
; /etc/rstudio-connect/rstudio-connect.gcfg [GitCredential] Host = github.com Username = accountName Password = <encrypted-string> Protocol = https
The encrypted string value of
should be generated via
You can support multiple hosts by including additional
Each host can only have a single credential. When configuring multiple
credentials, you must name each configuration section; if multiple
GitCredential share names, the last one will be used.
; /etc/rstudio-connect/rstudio-connect.gcfg [GitCredential "github"] Host = github.com Username = accountName Password = <encrypted-string> Protocol = https [GitCredential "selfhosted"] Host = git.mycompany.com Username = accountName Password = <encrypted-string> Protocol = https
Posit Connect can also use Git credentials for github.com, gitlab.com, and bitbucket.com to restore R packages from private Git repositories hosted on those services. See the section on using private R packages from private Git repositories for details.
Automatic fetch & deploy#
Git backed content differs from content that is directly published to Posit 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.
Periodic Git fetches are automatically performed at ~15 minute intervals for
each Git backed application. This interval duration may be modified via the
setting. To turn off automatic Git fetches entirely you may set the value to
The same polling frequency interval and re-deployment logic are used for public and private repositories.
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 Posit Connect. The size and composition of file based storage may likewise independently change over time.
All Git repository clones and cached metadata will be stored relative to the
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.
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.
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.
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