Repository files navigation

This solution contains the projects and resources that are hosted on aMicrosoft Azure virtual machine that serves therubberduckvba.com website.

• rubberduckvba.client
  The typescript/Angular front-end client; the actual website.

• rubberudckvba.Server
  The back-end server, served in production atapi.rubberduckvba.com.

• rubberduckvba.database
  The SQL Server database holding site data. The database is accessed using two connection strings, making it possible to write to test or production databases from a local debug session with a local hangfire server.

  • RubberduckDb is used for storing all content under the[dbo] schema
  • HangfireDb is used for accessing the[hangfire] schema (scheduled tasks)

• RubberduckServices
  Services involving Rubberduck 2.x libraries:

  • Rubberduck.Parsing.dll
  • Rubberduck.SmartIndenter.dll
  • Rubberduck.VBEditor.dll

Microsoft SQL Server Express is required; double-click therubberduckvba.database.localdb.publish.xml file under the database project to deploy the database schema locally. The Angular site should run out of the box, even without data.

Updating GitHub metadata requires a GitHub access token; configure user secrets to define the following values:

"GitHub:OrgToken":"required","GitHub:ClientSecretId":"optional","GitHub:ClientId":"optional",

WhereOrgToken is a validpersonal access token (PAT); generate one from your GitHub profile, underdeveloper settings.ClientId andClientSecretId are for OAuth login controllers, which was used by an older version of the site to grant certain content editing accesses to org members; create a GitHub OAuth application from your profile. The feature/content update pipelines use the PAT for credentials instead.

The server uses Hangfire to schedule and run background tasks, and creates two jobs at startup:

• update_installer_downloads is scheduled to run on a daily basis
• update_xmldoc_content is created but not scheduled

When triggered, theupdate_installer_downloads job creates a TPL DataFlow pipeline that can be documented as follows:

Essentially, we're hitting GitHub (using theGitHub:OrgToken credentials) to retrieve all tags from therubberduck-vba/Rubberduck repository. Once we have all the tags, we identify the currentrelease (main) andpre-release (next) tags and proceed to retrieve the xmldoc assets from these tags, and then we either update existing records with the updated data, or we insert new records with the new data - either way the website's front page displays updated figures and an updated timestamp immediately after it completes.

The task can be launched manually from the back-end API with an authenticated POST request to/admin/update/tags.

Similarly, this job creates a TPL DataFlow pipeline that can be documented as follows:

This pipeline hits GitHub to download the code inspections' default configuration from therubberduck-vba/Rubberduck repository, fetches the current-latest tags from the database to compare against the current-latest tags from GitHub, then downloads the .xml assets and parses them into "feature items" and proceeds to merge the contents:

• Items that exist innext but notmain are considered/marked as NEW
• Items that exist inmain but not innext are considered/marked as DISCONTINUED
• Items that exist in both branches get their content fromnext
• Items for which the json-serialized data has changed get updated; the others are left alone.

The task can be launched manually from the back-end API with an authenticated POST request to/admin/update/xmldoc; the endpoint is intended to be invoked by a webhook listening for GitHub tag/release activity, automatically updating the inspections, quickfixes, and annotations content accordingly.