Internal Documentation
Menu

Team Tools and Resources

Last updated: Sep-04-2025

On this page:

Overview

This guide provides comprehensive information about the tools, systems, and resources essential for documentation team productivity. It covers setup, configuration, best practices, and troubleshooting for all the technologies and services our team uses daily.

For information on setting up and running the documentation site locally, see development setup guide.

Text Editors and IDEs

Cursor (Primary Choice)

Cursor is our primary recommended IDE for documentation work. It provides enhanced AI-powered editing capabilities while maintaining full compatibility with VS Code extensions and settings.

Key Benefits:

  • AI-powered assistance - Context-aware code and content suggestions
  • VS Code compatibility - Import existing VS Code settings and extensions seamlessly
  • Enhanced productivity - Built-in AI chat and code generation
  • Familiar interface - Same UI as VS Code with additional AI features

VS Code (Alternative Option)

VS Code remains a solid alternative choice. Anyone using VS Code can easily migrate their settings and extensions to Cursor.

Essential Extensions

Markdown All in One

Enhanced markdown editing and preview capabilities essential for efficient documentation writing. Recommend using the fork of this which enables Cloudinary specific anchor link slug autocompletion.

Download the VSIX file

To install the VSIX file, open the Extensions view in VS Code (Ctrl+Shift+P > Extensions: Show All Extensions), click the ... menu next to the Cloudinary Docs Extension, and select "Install from VSIX...".

  • Allows you to hover over the partial name in the markdown to see the content of the markdown and a link to that partial.
  • Evaluates variables on the page

Update Markdown extension preferences:

After the extension is downloaded, in the top menu bar: Code > Preferences > Settings or for Cursor: Cursor > Settings > VS Code Settings.

Expand Extensions and scroll to Markdown All in One.

Near the bottom of that section, clear the checkboxes for Ordered list, Plain text for TOC, and TOC autoupdate on save.

Vale

Style and grammar linting extension that ensures consistency and quality across all documentation.

See Vale Linting/Spellcheck for more details.

cld_docs_extension

Cloudinary documentation-specific tooling that streamlines workflow with project-specific features.

Get extension here.

Download the VSIX file for the latest version from the releases page.

To install the VSIX file, open the Extensions view in VS Code (Ctrl+Shift+P > Extensions: Show All Extensions), click the ... menu next to the Cloudinary Docs Extension, and select "Install from VSIX...".

  • Allows you to hover over the partial name in the markdown to see the content of the markdown and a link to that partial.
  • Evaluates variables on the page

More to come.

Cloudinary Extension

Manage Cloudinary media assets from within the documentation.

Get extension here.

Download the VSIX file for the latest version from the releases page.

To install the VSIX file, open the Extensions view in VS Code (Ctrl+Shift+P > Extensions: Show All Extensions), click the ... menu next to the Cloudinary Docs Extension, and select "Install from VSIX...".

Update your configuration with all the product environments you'll need to use (own account, demo, cloudinary etc). You can now easily upload images to the relevant account and use them in the documentation.

Replacement MacBook Tips

Migrate VS Code settings - under Preferences, there's an option to enable "Settings sync". You can sign in with GitHub and all of your settings and extensions are synced, so when you enable "Settings sync" on your new mac it automatically works just like your old one.

Other Tools

Chrome Extensions

Cloudinary Media Inspector

Analyze and inspect Cloudinary media assets and transformations directly in the browser.

Install from the Chrome Web Store.

Debugger for Google Analytics 4 (GA4 Debugger)

Debug and monitor Google Analytics 4 tracking implementation on documentation pages.

Install from the Chrome Web Store.

Note
We once used DomainSwitcher to quickly switch between different environments and domains (configure dev, staging, and production domains) during testing and development, but it's now unavailable.

Installation was from the Chrome Web Store.

MCP Servers

  1. Required for KB migration - Install the Playwright MCP server. This provides advanced browsing tools which can better extract existing KB article content.
  2. Install the Cloudinary MCP servers if planning to use the MCP servers for testing.

Source Control

Git

It's each to their own when it comes to git. Main options:

  1. Command Line - old school for those that really know what they're doing.
  2. Built in git in Cursor/VS Code.
  3. SourceTree - a GUI for git.
  4. Other GUI options.

Git Branch Naming and JIRA-Git Auto Transitioning

Each JIRA that requires changes to Git files should have its own branch in cld_docs. The branch name should be in the format: DOC-XYZ_Short_Description.

As long as you follow this naming guideline, the JIRA will automatically change statuses with your GIT activity:

  • When you create a branch & push it to remote, the JIRA issue is moved from New to In Progress
  • When you create a pull request, the issue is moved to In Review
  • When you merge (or merge & squash) a PR, the issue is moved to Done

If you commit a small JIRA into a branch that is not named in the format mentioned above (or you commit it in a branch of another JIRA number) and you still comment the JIRA commit with the name of your JIRA, then although it won't move through the stages of In Progress & In Review, the JIRA will still automatically move to done when the parent branch is merged to master.

Quality Assurance

Vale Linting/Spellcheck

The Vale linter provides spellchecking, repeated words check and terms checks. The linter runs when a PR is open and when any changes are committed. The build will fail if there's any errors found and the file with the errors will have annotations.

Recommend installing the Vale CLI locally and optionally the VSCode plugin.

Vale CLI

Once installed, you can run a check locally against the whole of the documentation folder. Change to the dev/cld_docs directory and enter the following command:

Vale VSCode Plugin

  1. Install & enable the plugin & restart VS Code
  2. Open any doc .md file & show the VS Console (Problems tab)
  3. You can click any error/warning/suggestion to jump to it and fix it
  4. After fixing an error, save the file, and the error/suggestion should disappear from the console

Exceptions

Spelling Exceptions

If any spelling errors found aren't legitimate errors (e.g. it's a param or cld term etc), you will need to add an exception to the following file: .github/styles/config/vocabularies/cld/accept.txt

This text file contains a list which is roughly organized into categories and alphabetically sorted. You can add an exception to this file by adding the word to the relevant category. By default the file is case-sensitive, you can use this to enforce a certain case, but it many instances you will want to allow different cases, you can use some patterns for this:

  • Adding both cases of a letter in square brackets e.g. [Ww]ord
  • Adding (?i) before a word to allow any casing at all

You can also allow plurals of a word/term by adding the s in brackets with a ? after. E.g. word(s)?

Once updated, it's best to run Vale locally and verify you have no errors before committing and pushing.

Other exceptions

In general, we should try to keep error/warning/suggestion exceptions to a minimum. First think carefully whether there's a better way to write the sentence to match our style guidelines -- i.e. try to change passive to active voice, future to present, etc, even if it means rewriting the sentence and not just the highlighted phrase. Keep a phrase as two words instead of a contraction only if really essential to highlight a "not" or similar.

Only apply exceptions if you strongly feel that the sentence is the most correct when written as is.

To apply an exception for a block or inline, use the specific vale exclude syntax:

Wrap the relevant line(s) or text in {valeExclude}...{/valeExclude} tags.

For example:

A/B Testing System

The documentation site includes a comprehensive A/B testing system for content experiments.

Quick Reference/Links

How the A/B Testing Mechanism Works

This mechanism is used to test a single major change in the docs (adding/removing/reorg of multiple doc pages, changing cross-site CSS or other design elements, modifying the top or left menus, etc) by delivering the master branch (without the change) as the "A" or "control" and delivering a different branch as the "B" or "test" version.

The mechanism works via two different versions of the doc site to 2 different buckets in S3 (a test bucket and a control bucket).

A/B Test Cookie

While a test is enabled, when a user hits any doc page the mechanism checks whether the user already has an A/B testing cookie with that name. If not, it first randomly (according to the % defined for the tests) assigns the user either a 'test' cookie or a 'control' cookie with the test name.

  • Cookie name: cld_docs_ab_test
  • Values: control or variant
  • Duration: 30 days
  • Scope: cloudinary.com domain

If they already have a cookie, then it checks whether the user's cookie is test or control, and based on the value, it will deliver the requested page to the cloudinary.com/documentation domain by pulling the HTML page from the control bucket or from the test bucket.

A/B testing

When no test is running, everyone going to the main cloudinary.com/documentation domain receives pages only from the control bucket.

Tip

A/B Test Events

Every page that loads passes an env_details GA4 event that indicates whether there's currently a test active and indicates whether the page was loaded from the control or the test bucket.

A/B testing

A/B Test Footer

All pages in the test bucket also have an extra line in the footer indicating that the page is from the 'B' version to make it easy for us to see which page a user is looking at. It also lists the current build number, but that build number will change over the course of the test with each redeploy (whenever master is re-merged into the B test - as mentioned below, or whenever the B test is manually updated & deployed)

A/B testing

A/B test auto-merge

While an A/B test is enabled, any changes that are deployed to master are automatically also merged into the official A/B test branch (origin/docs-ab-testing) and automatically deployed to the 'B' bucket as well (via the Merge AB Test gitaction), so users who are getting either version will see all fixes, new features, etc.

This means that before deploying a new version, esp if it involves any major TOC, content, or doc site feature changes, you should think about how it might affect the test branch as well - depending what's being tested there and where needed test locally on a copy of the ab test branch before merging your change to master:

  • If the A/B test is under development, and you're testing a major change, you should do a local merge to the test development branch (named abtest/<jira-id>/description), and verify that it works smoothly there too.

  • If the A/B test is live, you may want to duplicate the official A/B test branch (origin/docs-ab-testing) and merge & test there

If there are any conflicts between master and the docs-ab-testing branch, the auto-merge will fail and a message will be sent to our doc_team slack channel:

DocsNotifications

Handling auto-merge conflicts

If the notification above appears in our doc-team channel after you do a merge to master:

  1. Pull the latest master and the latest docs-ab-testing branch locally

  2. Merge master into the docs-ab-testing branch - you should get conflicts

  3. Resolve the conflicts very carefully - if you're not the a/b test owner of the active a/b test, then reach out to them to be sure that your resolutions won't break anything.

  4. Test the resolved docs-ab-testing branch locally in the docs-dev env to make sure your new content looks good & the special "B" test content also looks/works as expected and commit.

  5. Manually deploy the docs-ab-testing branch using the Deploy A/B test gitAction. (Make sure you set the branch & don't accidentally deploy the default 'master').

  6. After the deploy completes, validate that test.cloudinary.com/documentation looks/works as expected.

Creating a new A/B test

  1. Create a test development branch off the latest master with the naming convention: abtest/<jira-id>/<descriptive_name>

  2. Implement the test - make sure nothing but the content/feature to be tested is changed in that branch. Never use that branch to make little fixes (i.e. a typo you come across, etc) that really belongs in master, etc - keep in mind that if the A/B test fails, nothing from this branch will ever get deployed to production.

  3. Sync with the data team & other stakeholders on the success criteria, events you need to evaluate that success, the timing for the test, etc.

  4. While developing & getting input, you can merge to staging (if your test contains different files and/or TOC structure from the control - consider keeping both old and new on staging).

  5. Before deploying the test, merge the latest master, and get all peer, SME, technical reviews and do extensive internal testing as you would for any major change going to production.

  6. If your test version has any pages that don't exist on the control version those pages will start getting indexed by google when your test goes live, but those links will return 404s for anyone receiving the control version. Therefore, create a new branch off the latest master (not off your ab-test), and add redirects for all the test pages that only exist in the test branch and redirect them to the most logical place in the master version. This special redirect branch should be merged to master immediately after your test version goes live (make sure it already has the relevant approvals etc).

    1. IMPORTANT!! If you create a redirects branch for the control version, and your AB test dev branch doesn't already have its own redirects (i.e. it would if it deletes pages from the original), then in your AB test dev branch also add one dummy redirect entry to the object-redirects file (i.e. redirect a fake page that doesn\'t exist to another fake page that doesn't exist).

      This is so that when you merge this redirect branch to master, the auto-merge to the ab branch will have a conflict. Otherwise it would successfully merge & deploy the redirects that go away from your new test pages into your test bucket.

Final Testing for an A/B Test

  1. Create a new branch off master and call it abtest/<testname>/_ab-release. Then open a PR from your ab-testing branch (abtest/<jira-id>_<descriptive_name>) but set the base to be this new abtest/<testname>_ab-release branch (which is currently identical to master).

  2. Get a final review and approval of this PR. After your A/B test goes live (see the last step of the Deploying procedure below), you'll merge your this PR into the ab-release branch, which will close the active AB test branch you've been working on until now.

    The *_ab-release branch will get any future fixes you might make just for the B test during the course of the active test (via separate fix branches that you merge to it) & it will ultimately be the one that gets merged to master assuming the test success criteria are met.

  3. Ensure that docs-ab-testing branch is an exact copy of master (with no old a/b test content in it. This should have already been done at the end of the previous a/b test (after it was either rolled out to master or decided not to release), but do it again to be sure - you can do this via git:

    • Make sure you're on the docs-ab-testing branch, pull the latest and run: git reset --hard origin/master git push --force

  4. Manually merge the latest version of your approved AB test branch into docs-ab-testing branch

  5. To be sure it looks exactly as you expect, deploy docs-ab-testing branch to nightly (not staging) and sanity test it.

Deploying & Enabling an A/B test

  1. In the cld_docs GitActions, run the Deploy A/B Test action with docs-ab-testing as the branch to deploy (the default is master - make sure to change it!). This will deploy the updated version of that branch to the S3 bucket associated with test.cloudinary.com/documentation.

  2. Take a look at the updates in the test.cloudinary.com/documentation domain and make sure everything is ready to go.

  3. Enable the test:

    a. Make sure that no other test is still running with a non-expired cookie. If it is, disable that test and validate that the cookie no longer exists.

    b. Navigate to the docs-a-b-testing repo GitActions (not cld_docs): https://github.com/CloudinaryLtd/docs-a-b-testing/actions

    c. Set the values for the Change A/B Testing Params workflow: 1. Keep the branch as master (it's the master of the a-b-testing repo) 2. Select the Enabled check box 3. Change the Exposure value to the right % for the test as agreed upon with the data team (i.e. 0.5 for 50% getting B, or 0.2 if only 20% should get B) 4. Set the Name to the test name agreed on with the data team 5. Set the Expiration date. This is the date that the test will stop running and the cookie with the specified test name will expire.

    Important - Even though we can manually stop the test earlier than the specified date, it's important not to set the expiration date unnecessarily far out, so that the cookie won't unnecessarily remain in customer's browser data.

    d. Run the Workflow. It only takes a few seconds.

    e. Open a new browser window and Inspect the Application cookies to make sure you're getting the expected CLDDocsABTest-<testname> cookie.

    Check if you get the test or control cookie and if the content is as expected for that version. You can then manually delete the cookie, refresh and check again till you get the other version (or try on other browsers) to validate that one as well.

    For each version, navigate to a variety of pages and make sure that you are consistently seeing the right version on all pages.

    f. If you created a redirects branch for master (as per this step in the test creation instructions), merge & deploy it right after the test version goes out. You should then get an auto-merge conflict notification in slack (assuming you added real or a dummy redirect in the test version as required):

    1. Resolve the conflict by keeping the dummy redirect in the AB test branch docs-ab-testing branch and manually deploy it to the test bucket using the Deploy A/B test gitaction.
    2. Go to the production.cloudinary.com/documentation(control bucket)

    g. Let the data team know that the test is live & that they should start collecting data.

    h. You can also check some of the standard data in our dashboard. 1. Page data - anything that you can filter by pages in the dashboard, you can look at for any pages that are only in the test version. 2. Links - In the link activity table (feature sheet), you can filter for pages where you have links that are unique to the test version and view the link activity.

Updating an existing (live) A/B test

As a general rule, you shouldn't update an A/B test once it's live, as that could skew data. However, if you discover a bug that\'s important to fix after the A/B test is live that's important for getting more accurate results from the test, you can update it:

  1. Pull the latest version of abtest/abrelease_<testname> and merge the latest master into it.

  2. Create a new branch from that updated version with the naming convention: abtest/abfix_<fix_description>

  3. Make the necessary changes, test locally, and open a PR against docs-ab-testing

  4. Get the relevant peer/stakeholder reviews and approvals.

  5. Once approved, merge your abfix_<fix_description> branch to docs-ab-testing.

  6. Manually deploy the docs-ab-testing branch using the Deploy A/B test gitAction. (Make sure you set the branch & don't accidentally deploy the default 'master').

  7. After the deploy completes, validate that test.cloudinary.com/documentation looks/works as expected.

  8. Merge your abfix_<fix_description> branch to abtest/abrelease_<testname>.

    (This is the 'release' branch that is the candidate to merge to master after the a/b test ends if we decide it's successful and should be released to all).

  9. Delete the abtest/abfix_<fix_description> branch (can be now or when you do your next github cleanup.)

Disabling an A/B test

  1. Navigate to the docs-a-b-testing repo GitActions (not cld_docs): https://github.com/CloudinaryLtd/docs-a-b-testing/actions

  2. Set the values for the Change A/B Testing Params workflow:

    a. Keep the branch as master (it's the master of the a-b-testing repo)

    b. Make sure the Enabled check box is NOT set

    c. Set the Name to the test name you want to stop.

  3. Run the Workflow. It only takes a few seconds.

  4. Open any doc page, open the Inspect console to the GA Debugger and check the env_details event It should say: ABTest: false

  5. Inspect the Application cookies to make sure no CLDDocsABTest- cookie exists.

Rolling out an A/B test to all (full release)

  1. If the A/B test has not already expired, disable the test.

  2. Merge the `abtest/abrelease_ to master.

  3. Test master on nightly to be sure everything looks good

  4. Deploy master to production

  5. Reset the docs-ab-testing branch. Make sure you're on the docs-ab-testing branch, pull the latest and run: git reset --hard origin/master git push --force

Cloudinary Internal Tools and Systems

Manual Hard Invalidation

To view a newly uploaded version of a file with existing transformation or for cached 404 error.

If you have a cached 404 error (you published a URL for a public_id that didn't exist), then if you later try to deliver a valid URL with that public ID, the cached error in the CDN will remain and the image won't display.

Same is true if you already released a particular transformation URL and then you overwrite the original image. The existing transformation URL remains cached, so you don't see the new image.

In this case, there's an internal feature (customers shouldn't know about it), which enables you to do an immediate manual invalidation of the broken URL.

URL: https://console.cloudinary.com/settings/settings/manual_invalidation

In the edit box, add the URL(s) you want to invalidate - each on a separate line, and click Save.

  • If you enter a URL with a specific transformation, only that specific transformation gets invalidated.
  • If you enter the URL for the original asset, all transformations on that asset get invalidated (meaning that the next time previously released transformations are requested for that asset, they'll be regenerated based on the newly uploaded version of that asset). This is usually the option you want.

Within a few seconds, the invalidation is done and the updated images should work.

Remember to run this in the same account as the URL. For example, if you're invalidating a URL in the demo cloud, you need to be logged into the demo console!

Testing Doc Behavior with Google Tag Manager Activated

By default Google Analytics and chat tools (both activated by Google Tag Manager) work only in production.

If you need to test something directly related to this functionality within our development environment, you can temporarily activate it locally:

In docs.html.haml, scroll to the GTM render statement and add true ||:

Caution
IMPORTANT: Make sure not to commit this change!

Upgrading to Paid on a Staging Cloudinary Account for Testing

Cloudinary has a 'fake' credit card that can be used to upgrade to paid accounts for the purposes of testing Console appearance/behavior for paid accounts. This should be done ONLY on a staging account & never on production.

In your staging account, click the Change Plan button.

In the Billing Address, you can fill in anything you like in all the required fields.

Credit Card details:

  • First Name: QA
  • Last Name: Testers
  • Card number: 4111111111111111
  • DD/MM: 09/29
  • CVV: 222

Checking GA4 Events

  1. Install Debugger for Google Analytics 4 Chrome extension & then close & reopen Chrome.

  2. Open the doc site (or any site that passes GA4 events) & then display the Chrome console. You should see a new tab called "GA4 Debugger"

  3. Do something on the page that passes a GA4 event. Examples in the doc site include - selecting an item from the top menu, clicking a tab in the code widget, changing the dark/light mode, clicking a link in the page, etc.

Here's a recording of how to use the Google Analytics Debugger as well as the GA4 site: GA4 Debugging Recording

If you have requests for analytics support, use this Monday form.

Checking Changes for Next Deploy

If we've merged a few different things to master, and before you deploy, you want to quickly check which new commits would be included in the next deploy (Diff since last deploy):

  1. Check the last tagged version of master. One easy way is to go into Jenkins, click the Documentation_PublishVersion link, and take a look at the last number in the Build History block on the left of the page.

  2. Switch to the master branch and then run the following git command:

Cleanup Remote Branches

This removes any local references to remote branches that have been deleted.

Ctrl-C Server Issues

When Ctrl-C doesn't successfully stop the cld_docs server:

  1. Find the process ID: bash lsof -i :3000

  2. Kill the process: bash kill -9 <ID number from previous command>

Example: bash kill -9 12345

Conflict Between Cloudinary CLI and Local Environment

Configuration of the Cloudinary CLI adds the following to your .bash_profile Terminal file: bash export CLOUDINARY_URL=cloudinary://APIKEY:SECRET@CLOUDNAME

This definition overrides the environment variable defined in our cld_docs project when we run it locally through the (puma) server via the terminal, and thus breaks links to images in the home page that are based on that environment variable.

Workaround - When you are ready to use cld-docs again after using CLI:

  1. Comment out any export CLOUDINARY_URL= lines in the .bash_profile file & save it. (The .bash_profile is located in your user directory as a hidden file -- use CMD-Shift-. (period) -- to display hidden files.)

  2. Stop the cld_docs server

  3. Completely close any open terminal windows you have (including any that may be running in an active IDE)

  4. Restart the cld_docs server (puma command).

  5. Reopen the docs-dev browser page and make sure the Home page is healthy.

Obviously you will need to uncomment these lines again to use the Cloudinary CLI.

Using AI APIs

Guidelines and procedures for using AI APIs in documentation work.

Open API Guidelines

You can find guidelines on working with Open API specs here (includes link to video): Open API Guidelines Google Doc

SDK References

JavaScript SDK Reference

Repository to clone: https://github.com/cloudinary/cloudinary_js.git (Clone it under your Development folder)

Source files: All *.coffee files (in src and subfolders) e.g.: cloudinary_js/src/*.coffee

To generate JSDoc preview: From Development/cloudinary_js, run:

Output is located in: cloudinary_js/doc/pkg-cloudinary-core/index.html

See also: SDK Style Guide

Deploying in GitHub

Testing on Staging

If you've made any significant restructuring changes, or just want to show your changes to people outside the Docs team, deploy your changes to the staging environment using the Deploy staging GitAction.

There are two ways to do this - directly in GitHub or via a VSCode extension.

Deploying in GitHub UI

Use the Deploy staging github job:

  1. Open cld_docs in github & click the Actions tab

  2. Select the Deploy staging action

  3. Click the Run workflow dropdown

  4. Change the "Use workflow from" branch to doc_staging (or whatever branch you need) - you can type to filter.

    Note
    Unfortunately, the default for this filter always matches the default branch defined for the repo & there seems to be no way to customize it just for this one action.

  5. Click Run workflow

Important deployment notes:

  • The deployment process includes deployment via CloudFlare CDN with caching that gets invalidated on each deploy. So new content will be accessible immediately after the deploy.

  • However, the setup also configures a 30min local browser cache TTL for better end-user performance. This means that even though we invalidate the CDN cache on deploy, you might still have to do a refresh/hard refresh in your browser to see a new change on a page you visited shortly before deploying.

Git Actions

Branch management:

In Run workflow you can specify any branch to deploy to the staging environment, but mostly we try to use the doc_staging branch so that different team members' changes can be viewed simultaneously. Merge your branch to the doc_staging branch and very carefully resolve conflicts before running the job.

Caution
When resolving conflicts, sometimes you'll want to accept new content coming in via the latest master content, but sometimes, you'll want to leave intentional differences that were already in staging - if you aren't sure which to keep for a particular conflict, check with the relevant writer for that feature.

GitHub Actions VSCode Extension

See attached video for instructions on using the GH Actions VSCode extension to trigger the builds.

Note
The branch will default to whatever branch you have active, in the video I manually updated this to doc_staging but in general, you'll probably be on doc_staging when you trigger the build as you'll have just merged something.

Potential Deployment Errors

If the job fails, search for "Error" in the Logs of the deployment job to determine the reason:

Example Error: ``` 14:03:04 I, [2020-08-21T13:03:04.676092 #36578] INFO -- : [8bc18175-32c4-41c7-b360-2e582457d286] Started GET "/documentation/get_started_tutorials.html" for 127.0.0.1 at 2020-08-21 13:03:04 +0000

14:03:04 /var/jenkins/workspace/documentation-team/Documentation_deploy_to_staging/lib/documentation_generator.rb:174:in `render_full': rendering returned error 404 (RuntimeError)

14:03:04 from /var/jenkins/workspace/documentation-team/Documentation_deploy_to_staging/lib/documentation_generator.rb:198:in `block in render_static'

14:03:04 from /var/jenkins/workspace/documentation-team/Documentation_deploy_to_staging/lib/documentation_generator.rb:197:in each' ``

Cause: get_started_tutorials.html was on the branch, but was not being referenced anywhere in the docs.

Resolution: delete the file get_started_tutorials.html.md.

QlikSense Documentation Dashboard

Accessing the Dashboard

The Doc Dashboard Overview page is here: QlikSense Doc Dashboard

From there, you can get to all the pages of the Doc Dashboard.

Tutorial Resources

Short video tutorials & notes about each page can be found here.

Viewing Support Tickets via QlikSense

Documentation bugs reported by CS are often related to a reported support ticket. In these cases, the support ticket is displayed in the issue with a link.

Unfortunately, there are not currently enough licenses to enable everyone to directly access support systems.

As a workaround, we can view the content of a particular ticket via QlikSense. To view it, use the following URL, but replace the number at the end with the number of the ticket you want to view:

https://bi.cloudinary.com/okta/sense/app/0ad13378-c269-4548-8337-376bc889ca7a/sheet/7728bf6c-2fe0-43fb-ac15-a51cb851d8ab/state/analysis/select/TicketID/97175

Related topics

✔️ Feedback sent!

Rate this page: