Does Workday Extend connect to GitHub?

Workday Extend keeps app source, versions and builds in App Hub, and you put that source under Git yourself with Local Disk Sync and the Workday Developer CLI (WDCLI). Workday's documentation describes no direct link that pushes GitHub commits into App Hub. A pipeline can upload, validate and promote with a WDCLI system user, but deploying to a tenant still needs a person's tenant sign-in.

App Hub stays the record Workday builds and deploys from; Git holds your branches, reviews and history. The workflow below keeps the two in step by making every App Hub upload come from a commit.

Get the app into a Git repository

Start from an app that already exists in App Hub; Local Disk Sync requires that.

  1. On the Developer Site, open the app and choose Download Source from the app's menu. Workday downloads a ZIP of the app's files. The CLI equivalent is wdcli app download <appRefId> --latest-version.
  2. Unzip it into a folder, check the expected files are there (pages, the site and app metadata, model and orchestration files), run git init, and make the first commit.
  3. Push to GitHub or any Git host.

Before the first commit, open the app's files and check whether anything tenant-specific or secret has been typed into them, such as a token pasted into an orchestration credential of type Token. Workday's guidance for Production is to use a Cred Store Reference for OAuth credentials, which keeps the secret in the tenant's credential store and only a reference name in the source. That habit also keeps secrets out of Git.

Edit through App Builder with Git as the working copy

Local Disk Sync turns a folder on your computer into App Builder's working copy, and Workday's own description of it names Git branching and merging as the purpose.

  1. On the Developer Site home page, from Build an Extend App (or Build an Integration App), select Open from Local Folder.
  2. Pick the repository folder. App Builder or Orchestration Builder opens in a local folder session, shown by a local folder indicator beside the app name.
  3. Edit as normal. Changes in the builder save to the folder automatically, and changes you make to the files outside the browser (a git pull, a merge, an edit in your own editor) show up in the builder immediately.

Three constraints from Workday's pages:

  • It works only in Chrome or a Chromium-based browser, and not offline.
  • You must choose Open from Local Folder every time you start a new session. Opening the app normally edits App Hub's copy, not your folder.
  • Saving locally isn't saving to App Hub. To deploy, use Save to App Hub in the builder or wdcli app upload. Workday states that you must save to App Hub before you can deploy a version.

A branching pattern that fits App Hub

App Hub has one Development version per app at a time: uploading changes to a version you haven't promoted updates that same version rather than creating a new one, per Concept: Update Workday Extend Apps. In Workday's example, version 2 appears only after version 1 has been promoted. So App Hub can't hold a separate copy per feature branch under the same reference ID.

A workable pattern, and it is a recommendation rather than a Workday rule: let developers work on feature branches locally, merge to main through pull requests, and let only main be uploaded to App Hub. If two developers each open their own branch with Local Disk Sync and save to App Hub, the last upload wins and the other branch's changes vanish from the build. Workday's Concept: App Hub also lets you delete an app from App Hub, after which no Development tenant can reach it, so treat App Hub write access as release access.

For a throwaway experiment that needs its own App Hub entry, wdcli app copy <appRefId> --name <newAppRefId> copies a local app to a new directory with a new reference ID. That is a separate app with its own reference ID, not a branch, so don't promote it.

Automate with WDCLI and a system user

WDCLI is the tool Workday documents for scripts and CI/CD pipelines (the WDCLI guide covers installing it and signing in). For a pipeline, create a system user so it doesn't sign in as a person:

  1. As a Developer Site admin, open the Users tab on the Console and click Add a User.
  2. Choose System User as the Company Role and save the Client ID and Client Secret that appear.
  3. In the pipeline, store them as encrypted secrets and expose them as WDCLI_CLIENT_ID and WDCLI_CLIENT_SECRET.
  4. Sign in with wdcli auth login --system-user.

A system user belongs to one organization and can't be used across several, which matters if you are a partner building for more than one customer: each customer's Developer Site needs its own.

A pipeline step on merge to main could then run:

wdcli auth login --system-user
wdcli app validate <appRefId>
wdcli app upload
wdcli app builds <appRefId>

wdcli app validate checks only App Builder components. Workday's command reference says orchestrations must be validated separately in Orchestration Builder, so a green validate step doesn't prove an orchestration builds. Read the build result with wdcli app builds and, for a failed build, wdcli app builds logs <buildId>; fail the pipeline if the latest build didn't pass, because promotion to Implementation takes the most recent passing build. The Extend validation errors guide explains the messages those logs contain.

wdcli app promote <appRefId> --level implementation can be a manual, approved pipeline step. The CLI follows the same promotion deadlines as the Developer Site, including the weekly cut-off for model components covered in the promotion guide.

Why deploys can't be fully automatic

Workday's WDCLI concept page is explicit: system user accounts can't run tenant-level operations such as deploying an app, which still requires signing in with tenant credentials. wdcli app deploy <appRefId> --tenant-alias <alias> --version <n> therefore runs after a person has signed in with wdcli tenant login <alias>. The tenant token is held for one tenant at a time; signing in to another overwrites it.

So the deploy step belongs to a person: a developer runs it after the pipeline has uploaded a passing build, or a pipeline job waits for someone to complete the tenant sign-in. Storing a person's tenant password in CI to get around this makes every deploy look like that person's, whoever triggered it.

Prove the repository and App Hub match

The check that matters is whether what's in App Hub came from a commit:

  • After an upload, wdcli app versions <appRefId> and wdcli app builds <appRefId> should show a new build with a passing status.
  • Download the source again with wdcli app download into a temporary folder and diff it against the commit you uploaded. Any difference means someone saved to App Hub outside the pipeline, usually from a builder session that wasn't opened from the local folder.
  • After a deploy, run the app in the Development tenant and confirm the change is there before you promote.

Tag the commit with the App Hub version you uploaded it as. App Hub's versions don't record a commit, so the tag is what tells you later which source an Implementation or Production version came from.

Sources checked