{"id":21491645,"url":"https://github.com/orgflow-actions/setup","last_synced_at":"2026-04-07T13:31:32.262Z","repository":{"id":43704220,"uuid":"455834441","full_name":"OrgFlow-Actions/setup","owner":"OrgFlow-Actions","description":"An action that installs and configures OrgFlow CLI and lets you build your Salesforce DevOps pipeline and manage your deployments from GitHub.","archived":false,"fork":false,"pushed_at":"2024-10-08T18:49:11.000Z","size":1165,"stargazers_count":1,"open_issues_count":1,"forks_count":0,"subscribers_count":0,"default_branch":"v1","last_synced_at":"2024-11-18T16:31:14.050Z","etag":null,"topics":["continuous-delivery","continuous-integration","devops","github-actions","orgflow","salesforce","salesforce-devops","salesforce-metadata"],"latest_commit_sha":null,"homepage":"https://www.orgflow.io","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/OrgFlow-Actions.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-02-05T10:06:11.000Z","updated_at":"2024-10-08T18:49:15.000Z","dependencies_parsed_at":"2024-11-19T04:57:44.382Z","dependency_job_id":null,"html_url":"https://github.com/OrgFlow-Actions/setup","commit_stats":{"total_commits":17,"total_committers":5,"mean_commits":3.4,"dds":0.4117647058823529,"last_synced_commit":"48a3f5b5a97cb7f15fadaa421e599de0ba71b0a9"},"previous_names":[],"tags_count":4,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OrgFlow-Actions%2Fsetup","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OrgFlow-Actions%2Fsetup/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OrgFlow-Actions%2Fsetup/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OrgFlow-Actions%2Fsetup/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/OrgFlow-Actions","download_url":"https://codeload.github.com/OrgFlow-Actions/setup/tar.gz/refs/heads/v1","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":226057478,"owners_count":17566955,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["continuous-delivery","continuous-integration","devops","github-actions","orgflow","salesforce","salesforce-devops","salesforce-metadata"],"created_at":"2024-11-23T15:17:14.362Z","updated_at":"2026-04-07T13:31:32.230Z","avatar_url":"https://github.com/OrgFlow-Actions.png","language":"TypeScript","readme":"# OrgFlow: Salesforce DevOps for GitHub\r\n\r\n\u003cp\u003e\u003cimg src=\"logo.svg\" alt=\"OrgFlow Logo\" width=\"200\"/\u003e\u003c/p\u003e\r\n\r\nOrgFlow is a cross-platform DevOps tool that opens the Salesforce platform up to modern software development, version control, deployment and automation techniques.\r\n\r\nMore information about OrgFlow:\r\n\r\n- Website: https://www.orgflow.io\r\n- Documentation: https://docs.orgflow.io\r\n- Blog: https://medium.com/orgflow\r\n\r\nThis action installs and configures OrgFlow on a GitHub Actions runner so that OrgFlow commands can be executed as normal shell script commands in subsequent steps. This allows you to use OrgFlow from GitHub Actions to build your Salesforce DevOps pipeline and manage your deployments from GitHub.\r\n\r\nThe following configuration steps can be performed by this action:\r\n\r\n1. Download OrgFlow\r\n2. Install OrgFlow and add it to `PATH`\r\n3. Configure diagnostic logging\r\n4. Validate and save your license key\r\n5. Save Salesforce credentials\r\n6. Configure Git authentication and committer signature\r\n7. Set default stack\r\n8. Upload diagnostic log files and bundles as artifacts during post-job processing\r\n\r\nRunning this action at the start of your workflow job allows you to run any OrgFlow commands with minimal hassle in subsequent steps of your job, without having to provide any of the above configuration again.\r\n\r\nSee also:\r\n\r\n- Our [`demo`](https://github.com/OrgFlow-Actions/demo) template repository that contains a set of basic sample workflows that show how to use OrgFlow in GitHub Actions\r\n- Our [`result-to-comment`](https://github.com/OrgFlow-Actions/result-to-comment) action which allows you to post the results of an OrgFlow command as a comment on a GitHub issue or pull request\r\n\r\n## Supported platforms\r\n\r\nThis action works on:\r\n\r\n- GitHub-hosted runners and self-hosted runners\r\n- Ubuntu, macOS and Windows\r\n- With or without a container (also works with the `orgflow/cli` Docker image)\r\n\r\nGit version 2.39 or later is required. When running on GitHub-hosted runners or on our Docker images, all requirements are met.\r\n\r\n## Inputs\r\n\r\n| Name                   | Required? | Default                                                    | Description                                                                                                                                                                       |\r\n| ---------------------- | :-------: | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\r\n| `version`              |           |                                                            | Version of OrgFlow to install. Can be specified as major '1', minor '1.1' or patch '1.1.1'; latest matching version will be installed (omit to install latest available version). |\r\n| `include-prerelease`   |           | `false`                                                    | Set to 'true' to include prerelease versions when determining latest available version.                                                                                           |\r\n| `skip-install`         |           | `false`                                                    | Don't download and install OrgFlow (i.e. assume OrgFlow is already installed).                                                                                                    |\r\n| `license-key`          |  **Yes**  |                                                            | Your OrgFlow license key (you can get one at https://www.orgflow.io/trial if you do not already have one).                                                                        |\r\n| `salesforce-username`  |           |                                                            | Save username for connecting to production Salesforce org (stored on runner in encrypted form).                                                                                   |\r\n| `salesforce-password`  |           |                                                            | Save password for connecting to production Salesforce org (stored on runner in encrypted form).                                                                                   |\r\n| `git-username`         |           |                                                            | Save username for connecting to remote Git repository (not needed if connecting to a GitHub repository).                                                                          |\r\n| `git-password`         |           |                                                            | Save access token or password for connecting to remote Git repository (use `secrets.GITHUB_TOKEN` if connecting to the current repository).                                       |\r\n| `git-committer-name`   |           | `OrgFlow Default Committer`                                | Set name to use in committer signature when committing changes to Git repository.                                                                                                 |\r\n| `git-committer-email`  |           | `defaultcommitter@orgflow.io`                              | Set email address to use in committer signature when committing changes to Git repository.                                                                                        |\r\n| `stack-name`           |           |                                                            | Name of OrgFlow stack to save credentials for (required when saving Salesforce or Git credentials).                                                                               |\r\n| `encryption-key`       |           |                                                            | Encryption key to use when encrypting and decrypting Salesforce and/or Git credentials (omit to generate a new encryption key).                                                   |\r\n| `log-file-name`        |           | `{C}-{T:yyyyMMdd-HHmmss-FFF}.log`                          | Name (optionally tokenized) of OrgFlow diagnostic log files.                                                                                                                      |\r\n| `log-level`            |           | `verbose`                                                  | Verbosity level for OrgFlow diagnostic log files (verbose, debug, information, warning, error or fatal).                                                                          |\r\n| `upload-diag-artifact` |           | `true`                                                     | Set to 'false' to disable uploading of all OrgFlow diagnostic log files and bundles during post-job processing.                                                                   |\r\n| `diag-artifact-name`   |           | `orgflow_diag_${{ github.job }}_${{ github.run_attempt }}` | Name to use for the artifact when uploading OrgFlow diagnostic log files and bundles.                                                                                             |\r\n\r\n## Outputs\r\n\r\n| Name             | Description                                                    |\r\n| ---------------- | -------------------------------------------------------------- |\r\n| `version`        | Exact version of OrgFlow that was installed and/or configured. |\r\n| `encryption-key` | Encryption key that was saved.                                 |\r\n\r\n## Examples\r\n\r\nSee our [demo repository](https://github.com/OrgFlow-Actions/demo) for a set of complete sample workflows using this action. There you will also find a guided tutorial on how to set up a working end-to-end Salesforce DevOps pipeline using GitHub Actions.\r\n\r\nBelow are some very basic examples.\r\n\r\nInstall latest version and run a simple command to list all the current stacks in your OrgFlow account:\r\n\r\n```yaml\r\njobs:\r\n  orgflow_job:\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n      # Download and install latest version\r\n      - uses: orgflow-actions/setup@v1\r\n        with:\r\n          license-key: ${{ secrets.ORGFLOW_LICENSEKEY }}\r\n        env:\r\n          ORGFLOW__ACCEPTEULA: \"true\"\r\n      # Run command to list stacks in your account\r\n      - run: orgflow stack:list\r\n```\r\n\r\nInstall latest 2.0.x version, save Salesforce credentials and flow metadata changes from one sandbox environment to another:\r\n\r\n```yaml\r\njobs:\r\n  orgflow_job:\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n      # Download and install latest 2.0.x version\r\n      - uses: orgflow-actions/setup@v1\r\n        with:\r\n          version: \"2.0\"\r\n          license-key: ${{ secrets.ORGFLOW_LICENSEKEY }}\r\n          salesforce-username: ${{ secrets.SALESFORCE_USERNAME }}\r\n          salesforce-password: ${{ secrets.SALESFORCE_PASSWORD }}\r\n          stack-name: MyStack\r\n        env:\r\n          ORGFLOW__ACCEPTEULA: \"true\"\r\n      # Run command to flow changes from Dev sandbox into QA sandbox\r\n      - run: orgflow env:flowmerge --from=Dev --into=QA\r\n```\r\n\r\nPlease refer to the [command reference page](https://docs.orgflow.io/reference/commands/help.html) in our docs for a complete list of available OrgFlow commands that you can use in your workflow.\r\n\r\n## License key\r\n\r\nYour license key acts as your OrgFlow authentication mechanism, and allows your GitHub Actions workflows to access your OrgFlow account containing all the information about your stacks and environments and their current state. Your license key also validates your right to use the product for as many stacks and Salesforce orgs as are included in your license.\r\n\r\n**You can try OrgFlow completely free for 2 months** - no limits, no strings attached, and no credit card required. To obtain a free trial license key, simply visit https://www.orgflow.io/trial and enter your email address, and a trial license key for 2 months of unlimited use will be sent to you in email.\r\n\r\nA license key is required for all OrgFlow operations. By providing your license key to this action using the `license-key` input, your license key is validated and then saved locally on the runner so that you do not need to provide it on subsequent steps.\r\n\r\nAlternatively, you are prompted to request a trial license the first time you run OrgFlow from a local interactive terminal session.\r\n\r\n**Please use a secret to store your license key!**\r\n\r\n## Environment variables\r\n\r\nThe environment variable `ORGFLOW_ACCEPTEULA` is required to be present with the value `true` when running this action. Setting this environment variable constitutes your acceptance of our End-User License Agreement (EULA) which is available in full at https://www.orgflow.io/eula/cli. You do not need to provide this environment variable in subsequent steps.\r\n\r\nOrgFlow also supports several other environment variables for advanced configuration scenarios. Please refer to the [configuration reference page](https://docs.orgflow.io/reference/configuration.html) in our docs for more information.\r\n\r\n## Skipping download and installation\r\n\r\nYou can use the input `skip-install: \"true\"` to bypass downloading and installing OrgFlow on the runner.\r\n\r\nThis can be useful in scenarios where you know that the correct version of OrgFlow is already installed, such as:\r\n\r\n- When running your job on our `orgflow/cli` Docker image\r\n- When running your job on a self-hosted runner where you have already installed OrgFlow\r\n\r\n## Salesforce authentication\r\n\r\nOrgFlow needs a Salesforce username and password to interact with your Salesforce environment (e.g. to retrieve and deploy metadata, create and delete sandboxes, etc). In most cases, OrgFlow needs only the username and password for your **production** org, and can infer the correct credentials for any sandbox based on that.\r\n\r\nThere are two ways to manage Salesforce authentication for your GitHub Actions workflows:\r\n\r\n### 1. Store Salesforce credentials as secrets in GitHub Actions\r\n\r\nThis is the simpler option, and is recommended if you intend to drive your DevOps pipeline primarily from GitHub.\r\n\r\nUse the following inputs to this action to save the Salesforce credentials in encrypted form locally on the runner so that subsequent OrgFlow commands can authenticate with your Salesforce environments transparently:\r\n\r\n```yaml\r\nsteps:\r\n  - uses: orgflow-actions/setup@v1\r\n    with:\r\n      # Store Salesforce credentials encrypted on the runner:\r\n      salesforce-username: ${{ secrets.SALESFORCE_USERNAME }}\r\n      salesforce-password: ${{ secrets.SALESFORCE_PASSWORD }}\r\n      stack-name: SomeStack\r\n  # OrgFlow can now authenticate to Salesforce transparently:\r\n  - run: orgflow env:flowin --environment=SomeEnvironment\r\n```\r\n\r\n### 2. Store Salesforce credentials in OrgFlow's state store\r\n\r\nThis option is slighly more advanced and flexible, and can be useful if you want to use the stored Salesforce credentials both in CI/CD pipelines and during manual use in local terminal sessions, particularly across many different client devices and/or different users.\r\n\r\nTo use this option, use the [`auth:salesforce:save`](https://docs.orgflow.io/reference/commands/auth-salesforce-save.html) command in a local terminal session to encrypt and store your Salesforce credentials in the state store. Be sure to make note of the encryption key so that you can make it available as a secret to your workflows.\r\n\r\nWith this option, you do not use the `salesforce-username` and `salesforce-password` with this action, but instead you provide your existing encryption key using the `encryption-key` input. This key is then saved on the runner, allowing subsequent OrgFlow commands in your workflow to fetch and decrypt Salesforce credentials from the state store and authenticate with your Salesforce environments transparently. Example:\r\n\r\n```yaml\r\nsteps:\r\n  - uses: orgflow-actions/setup@v1\r\n    with:\r\n      # Provide your own encryption key:\r\n      encryption-key: ${{ secrets.ORGFLOW_ENCRYPTIONKEY }}\r\n      stack-name: SomeStack\r\n  # OrgFlow can now authenticate to Salesforce transparently:\r\n  - run: orgflow env:flowin --environment=SomeEnvironment\r\n```\r\n\r\n**Remember to use secrets to store any Salesforce credentials or encryption keys!**\r\n\r\n## Git authentication\r\n\r\nOrgFlow uses a Git repository in order to store your Salesforce metadata, create branches, commit and push metadata changes, etc. While it's common (and recommended) to keep the workflows that drive your Salesforce DevOps pipeline in the same repository as your actual Salesforce metadata, this is not a requirement. You can use any standard Git repository for this purpose, as long as it is reachable by the runner.\r\n\r\nYou configure which Git repository URL to use for metadata version control when you create your stack using the [`stack:create`](https://docs.orgflow.io/reference/commands/stack-create.html) command, which you normally run in a local terminal session as a one-time setup before building out your GitHub Actions based DevOps pipeline.\r\n\r\n**If your workflow runs in the same GitHub repository where you keep your Salesforce metadata, you do not have to specify any Git credentials yourself.** This action will default to using the `GITHUB_TOKEN` secret automatically provided by GitHub to set up authentication against the repository. The access level granted by this token is subject to the security configuration of your repository.\r\n\r\nHowever, if your Salesforce metadata is kept in a different Git repository, then you can use the following inputs to this action to save the Git credentials in encrypted form locally on the runner so that subsequent OrgFlow commands can authenticate with your remote Git repository transparently:\r\n\r\n```yaml\r\nsteps:\r\n  - uses: orgflow-actions/setup@v1\r\n    with:\r\n      # Provide credentials for your Git repo:\r\n      git-username: ${{ secrets.GIT_USERNAME }}\r\n      git-password: ${{ secrets.GIT_PASSWORD }}\r\n      stack-name: SomeStack\r\n  # OrgFlow can now authenticate to Git transparently:\r\n  - run: orgflow env:flowin --environment=SomeEnvironment\r\n```\r\n\r\nFor most public Git services such as GitHub, Azure Repos, BitBucket etc., you would issue a _personal access token_ (PAT) and use this as the `git-password` input while omitting the `git-username` input.\r\n\r\n**Remember to use secrets to store your Git credentials!**\r\n\r\n## Versioning\r\n\r\nAll of our `orgflow-actions/*` actions are semantically versioned. Breaking changes will cause a major version bump.\r\n\r\nAll releases are tagged with a full version number, e.g. `v1.1.0`. You can use these tags to pin your workflow to a specific release, e.g. `@v1.1.0`.\r\n\r\nWe also maintain branches for each major version of our actions, and you can reference branch names to ensure that you are using the most up to date version of this action for a specific major version. For example `@v1` would cause your workflow to automatically use the most up to date `v1.x.x` version of this action.\r\n\r\n## Troubleshooting\r\n\r\n### Workflow logs\r\n\r\nTo enable more detailed log output from this action, enable **step debug logs** for your workflow by adding the secret `ACTIONS_STEP_DEBUG` with the value `true`. You can also enable **runner debug logs** by adding the secret `ACTIONS_RUNNER_DEBUG` with the value `true`.\r\n\r\nMore information here:\r\nhttps://github.com/actions/toolkit/blob/main/docs/action-debugging.md\r\n\r\n## OrgFlow diagnostic logs\r\n\r\nThis action enables and configures OrgFlow diagnostic logging, both for this action and for all subsequent OrgFlow commands you run in your job. By default the log level is set to `verbose`, and a separate log file is written for each OrgFlow command executed throughout your job, based on the command name and time using the log file name pattern `\"{C}-{T:yyyyMMdd-HHmmss-FFF}.log\"`. The exception is log output collected during the setup action itself, which is instead written to `\"setup.log\"`.\r\n\r\nYou can override the naming of diagnostic log files using the `log-file-name` and `log-level` inputs. The `log-file-name` input supports several tokens you can use to base log file names on values only known at runtime. Please refer to the [logging section in our documentation](https://docs.orgflow.io/troubleshooting/logging.html) for more information about specifying log file names and log level.\r\n\r\nThis action also contains a post-job step that collects all OrgFlow diagnostic log files and bundles written throughout your whole job, and uploads them as an artifact on your workflow run named `orgflow_diag_\u003cjob\u003e_\u003cattempt\u003e`. This can be very useful during troubleshooting. You can change the artifact name using the input `diag-artifact-name`. If you wish to disable the uploading of this artifact for any reason, you can do so by specifying `upload-diag-artifact: \"false\"` as an input to this action.\r\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Forgflow-actions%2Fsetup","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Forgflow-actions%2Fsetup","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Forgflow-actions%2Fsetup/lists"}