Can't deploy to RSC without special rights on the server due to vanity url

[cderv]

The issue

As discussed, I am currently testing how to use GHA to deploy some usual R Markdown related project. I am looking at bookdown currently.

I have tested several deployment methods in https://github.com/cderv/deploy-bookdown-demo

When I tried the connect-publish action on https://beta.rstudioconnect.com, I can't publish because the action has a prerequisite of the API KEY having the right to set vanity url for a content. And this is not the case by default: https://docs.rstudio.com/connect/admin/appendix/configuration/#Authorization.PublishersCanManageVanities

That means, the content is created correctly on RSC but we have an error because the vanity path the action is creating for a new content can't be set. here is the error: https://github.com/cderv/deploy-bookdown-demo/runs/1533824331?check_suite_focus=true#step:9:5530

Discussion about the context and possible solutions

One solution would be to have the setting change on the server, but I don't think that connect-publish action should be dependent on a server setting

I think this should evolve. I understand main questions are:

1. How to identify a content ?
2. How to create a new content (no identifier yet) and still republishing into it later without changing anything ?

The action here tries to deal with both, as the rsconnect::deployApp() function. Let's recall that base principle for publishing on connect is (based on the API)

1. Create a content -> get a GUID
2. Deploy a bundle to the content
3. Activate the content

And I am guessing you are using that in the action too using the API right ?

About "How to identify a content ? ", AFAIK an app as several identifier

1. A GUID
   • internal thing but shown in the info tab for every app.
   • Unique server-wide.
   • Used in the API to identify a content.
2. An ID
   • which in the default url of the app page.
   • Unique server-wide, and incremental.
3. A name
   • internal thing also I believe
   • provided to rsconnect::deployApp or the API when creating a content
   • registered in the DCF file in rsconnect folder
   • Unique within the server or maybe within an account (which would make [ (users/api key) / (name) ] a unique thing)
4. A vanity path (optional)
   • if set, it will indeed be unique.
   • Otherwise, it is the id (/content/<id>)

What about those choice for the actions:

• Currently the action is using the Vanity Url which is the only optional identifier - that is causing the issue above. You need admin rights or non default config on RSC server.
• GUID and ID can't be chosen by the user - they are automatically attributed to new content. That means, for a new first deployment, the action would have to cache the information to be able to republish later. Like rsconnect package which cache information in dcf in the rsconnect folder. GHA cache could be use the same way - but is it enough reliable ? If this info is lost, the ID or GUID would need to be set manually (related to #11). They are useful for deploying on an existing content though.
• That leaves us with the unique app name. A user could decide which name to set, it has to be unique for RSC server-wide (or account-wide). So I think it is good properties for what is need for this action. Only drawback: It don't seem to be useful to use the action to publish on existing content (#11) as it does not seem easy to retrieve the app unique name identifier - I can't find the info the the INFO pane in RSC - only title (non unique I think), GUID and ID (in the url). You could retrieve by the API but... you need the GUID.

So at last, maybe not using the vanity url but the app name instead would be enough for the connect-publish action. Taking the example in #11

      - name: Publish the book
        uses: rstudio/actions/connect-publish@main
        with:
          api-key: ${{ secrets.RSC_BETA_TOKEN }}
          url: https://beta.rstudioconnect.com/
          access-type: logged_in
          dir: _book
          name: demo-bookdown-deploy

I just don't know how easy it would be using the API to find if the content exist. It depends if the name is unique server-wide or account-wide maybe.

Anyway, opening this for discussion. You may have already thoughts on this.

[meatballhat]

The current behavior should be that each directory may be specified with an app identifier suffix such as a vanity path, name, or GUID, e.g.:

      - name: Publish the book
        uses: rstudio/actions/connect-publish@main
        with:
          api-key: ${{ secrets.RSC_BETA_TOKEN }}
          url: https://beta.rstudioconnect.com/
          access-type: logged_in
          dir: _book:demo-bookdown-deploy

In the case of publishing to an RStudio Connect server where vanity paths may not be changed by users with the publisher role, the request to update will fail, but publishing will continue. This is the reasoning behind the introduction of require-vanity-path, which changes the behavior to interrupt publishing when the vanity path cannot be updated. Please reopen if you're still seeing unexpected behavior :grin:

[cderv]

Great, thanks for the addition of require-vanity-path !

That is indeed working - vanity url is still trying to be set even if app name is provided (not a vanity url) but the request is failing and the deployment continues. I am still getting an error but that is another issue I think.