bitrise-workflow-editor - GitLite

KO | EN

gitlite — search

#javascript #python #hacktoberfest #typescript #llm #go #golang #machine-learning #linux #nodejs #macos #cli #ios #mcp

bitrise-workflow-editor

(★ 115)

Bitrise Workflow Editor

File Explorer

Download Latest Version (.zip)

- pre-commit
- - mockServiceWorker.js
- deploy-storybook.js
- main.ts
- preview.tsx
- compile_api.sh
- forkpty-Darwin-x86_64
- forkpty-run.sh
- run_api.sh
- set_version.go
- set_version.sh
- - config.go
- - bitrise_config.go
  - bitrise_config_test.go
  - bitrise_config_tree.go
  - bitrise_config_tree_test.go
  - bitrise_secrets.go
  - bitrise_secrets_test.go
  - common.go
  - connection.go
  - default_options.go
  - default_options_test.go
  - step_info.go
  - step_info_test.go
  - steplib_spec.go
  - steplib_spec_test.go
- - tools.go
- - utility.go
  - utility_test.go
- api_server.go
- routes.go
- root.go
- version.go
- - Dockerfile
- discuss_release.mustache
- github_release.mustache
- - arrow-down-dark.svg
  - bitrise-logo.svg
  - error-hairball.svg
- - main.tsx
  - monaco-workers.ts
  - proxy-worker.js
  - proxy-worker.jsonc
  - routes.tsx
  - yaml.worker.ts
- index.html
- - zustand.ts
- - test_bitrise.secrets.yml
  - test_bitrise.yml
- set-node-env.ts
- setup-jest.ts
- smoke.spec.ts
- yaml-helper.ts
- build.go
- version.go
.editorconfig
.gitignore
.lintstagedrc.json
.mcp.json
.tool-versions
bitrise-plugin.yml
bitrise.yml
CLAUDE.md
eslint.config.mjs
go.mod
go.sum
gows.yml
jest.config.cjs
knip.json
LICENSE
main.go
package-lock.json
package.json
playwright.config.ts
README.md
release_config.yml
renovate.json
tsconfig.json
vite-env.d.ts
vite.config.ts

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

![Build status](https://app.bitrise.io/app/1686da85b5935fd6.svg?token=7HlnSBadcyLcUnzq0ws4Nw)

# Bitrise Workflow Editor

> **Note: project is going through AngularJS -> React transition.
> Please read more about this in
>
the [wiki section](https://github.com/bitrise-io/bitrise-workflow-editor/wiki/Angular-js-to-React-transition-timeline).
**

## How to install & use the Workflow Editor on your Mac/Linux

1. Install [Go](https://golang.org) `brew install go` (on macOS)
1. Install the latest [Bitrise CLI](https://bitrise.io/cli) - it's a single binary command line tool
1. Run `bitrise setup` just to be sure everything's prepared
1. `cd` into a directory where you have your `bitrise.yml`, and run: `bitrise :workflow-editor`

That's all. The Workflow Editor is now part of the Bitrise CLI core plugins, so you don't have to install it manually.

To upgrade to the latest version of the Workflow Editor run:

```
bitrise plugin update workflow-editor
```

_Join the Workflow Editor's discussion
at: [https://discuss.bitrise.io/t/workflow-editor-v2-open-source-offline-workflow-editor/39](https://discuss.bitrise.io/t/workflow-editor-v2-open-source-offline-workflow-editor/39)_

## Install requirements

Workflow editor uses webpack for static asset compilation and asset bundling. For transformation we need to use some
rails related transformation hence it also uses bundler to install ruby dependencies. In addition it uses karma and
jasmine for frontend tests execution so it needs `node` and `npm` installed to get the dependencies for testing and also
production.

Finally the local executable is written in GO. so you need to have go set up as well and dependencies.

```bash
bitrise run setup
```

## Development

### Build a stand-alone binary, with embedded resources

```
go install
```

### Run in development mode

```bash
npm start          # start both local plugin api and webpack dev server
```

1. In your browser, you can reach the Workflow Editor on `localhost:4000/{version}`. Be aware that you usually have to
   wait a while until dev server starts up (then refresh)
1. By default, the Workflow Editor will open the `test_bitrise.yml` from integration folder (used for integration
   testing). Please do not commit this file if you have any changes with it (e2e tests would fail).

If you would like to run the Workflow Editor in `website` mode, you have to run the dedicated npm command:

```bash
npm run start:website   # starts WFE in website mode
```

You also have to make sure that the Monolith is already running before you try to execute the command above (otherwise
every request to `http://localhost:3000` will be handled by the WFE).

`start:website` defaults to `PUBLIC_URL_ROOT=/workflow_editor`, so the HTML emits asset URLs that route through the
monolith's `/workflow_editor/*` asset proxy. Point the monolith at your local WFE by setting the env var below (no
controller-source edits needed):

- if you run the monolith directly (umbrella repo): `BITRISE_WORKFLOW_EDITOR_URL=http://localhost:4000/workflow_editor`
- if you run the monolith in docker (`web-dev-env`): `BITRISE_WORKFLOW_EDITOR_URL=http://host.docker.internal:4000/workflow_editor`
  (or `http://workflow-editor:4000/workflow_editor` when both run on the same compose network)

Once the above is set, the Workflow Editor is reachable in the monolith
on `localhost:3000/app/{slug}/workflow_editor`.

If you want the browser to fetch assets directly from the WFE dev server (skipping the monolith proxy — faster, but
only works when the browser is on the same host as Vite, so not for remote dev boxes), override the prefix:

```bash
PUBLIC_URL_ROOT=http://localhost:4000 npm run start:website
```

In that case set `BITRISE_WORKFLOW_EDITOR_URL=http://localhost:4000` (no trailing path) in the monolith.

#### Restart after a version bump

If you pull/rebase across a release commit (one that bumps the version in both `package.json` and
`version/version.go`), restart the WFE — don't just rely on Vite's hot-reload. Vite picks up the new version from
`package.json` and starts serving at the new `/{version}/` path, but `go run main.go` keeps running its already-compiled
binary with the old `version.VERSION` constant. The two then disagree on the route prefix and requests 404 (which
surfaces in the monolith as `OpenURI::HTTPError 404` from `WorkflowController#content`).

### Run client tests

```bash
npm test        # run unit tests on already compiled client
npm run e2e:api # run only the local binary api for e2e tests
```

_NOTE: for e2e testing you could start a service normally with `npm start` (to develop and run tests on it parallel) or
have a binary ready by `bitrise run setup` if you only want to verify the correctness of an already built
feature. And then run the test dashboard with `npm run e2e:dev`_

If you only iterate on tests, you can also use `npm run test` as it skips transpilation and the transpilation and run
the tests on an already transpiled JS.

### Override LaunchDarkly flags

You can create an `ld.local.json` file in the project root to override the LaunchDarkly flags.

Example `ld.local.json` content:

```json
{
  "enable-nice-feature": true,
  "key-of-the-feature-flag": "local value of the feature flag"
}
```

# Contributing

This project is using squash & merge model, feel free to have as many commits as you like but at the end the work will
end up on master as a single commit.

## Tech standards

1. Every new feature has to be created in typescript and React (
   see [wiki](https://github.com/bitrise-io/bitrise-workflow-editor/wiki/React-from-angularjs-best-practices) for
   integration guides).
1. If you touch legacy code, consider porting it to new standards or if that's not possible use ES5 syntax! There are no
   transpilation for legacy codes (only minification).
1. For tests you are safe to use whatever standards jsdom executes (ES6 supported).
1. Use CSS for styling (try to use local components style if possible)

## Testing standards

1. Unit tests are required for every new feature
1. Consider writing React Testing library component tests

## New version release

Every master commit is released to an S3 bucket and Bitrise will integrate it with the website manually (CD is planned
when test coverage and confidence is increasing with the editor). If you wanna do a plugin release as well you need to
tag the PRs with `#plugin` wherever in the PR title (like: "new feature #plugin").

If new release requires Bitrise CLI to be updated, in `bitrise-plugin.yml` change `min_version` requirement of
the `bitrise` tool to the required CLI version.

## Testing if version release works, without actually releasing

- In bitrise.yml, create a workflow e. g. `test-release`
- From the `create-release` workflow, copy-paste the _GitHub release_ and _Create Discuss topic_ steps.
- In the GitHub release step, remove the `files_to_upload` input, set the `$NEW_RELEASE_VERSION` everywhere to something
  arbitrary, same for the `body`, and **most importantly set `draft: 'yes'`**
- In the Create Discuss topic step, **change the `DISCUSS_CHANGELOG_CATEGORY_ID` to the ID of one our
  discuss.bitrise.io's internal channels' ID** (you can find an ID using the Discourse API with a cURL request) so that
  it is only visible to us; also change the `title` and the `raw` parameter to something arbitrary.
- After the test release process, don't forget to delete the draft release and the internal changelog topic.