Creating a local development environment

[AleksandarCole]

Problem Statement

Currently, there is no documented way for developers to run Semaphore Community Edition in a local environment. This creates a significant barrier for contributors who cannot quickly test their changes before submitting them. The absence of a fast feedback loop makes contributing more difficult and time-consuming.

Current State

• No documented method to run Semaphore locally
• Contributors must submit changes without local testing
• UI changes are particularly difficult to test

Desired Outcome

A simple, documented way for contributors to:

• Set up a local development environment
• Test changes quickly and efficiently
• Validate functionality before submitting PRs

Discussion Points

• What should be our MVP for local development?

  • @DamjanBecirovic proposed to focus on front service for UI changes

• What technical requirements should we consider?

• How comprehensive should our documentation be?

  • Setup instructions
  • Troubleshooting guide
  • Environment verification
  • Common development workflows

• What are the limitations we should communicate?

  • Features that cannot be tested locally
  • Performance differences
  • Potential configuration variations

Next Steps

Let's discuss these points to create a plan for implementing and documenting a local development environment, with initial focus on enabling UI development and building up from there.

[AleksandarCole]

@radwo you did some R&D in this area. Please share insights when you get the chance.

[radwo]

I have my changes in this branch: main...local/skaffold.

Current status:

• I’m encountering the error "Error occurred while fetching authorization URI" on the /login page. I suspect this is due to a missing certificate. Fixing this and booting semaphore is my first priority.
• Another issue is that the initial setup takes around 30 minutes to build all the images. Additionally, all images are built using the production setup, meaning even a small change requires a full rebuild of the image.

Once I get Semaphore running locally, I’ll focus on optimizing the build process to reduce these inefficiencies.

[AleksandarCole]

Decision

After discussions with @VeljkoMaksimovic, we've aligned on the primary goal: enable contributors to test their changes without spending more than 1 hour setting up a testing environment.

This doesn't necessarily require Semaphore to run locally. A streamlined release/deployment process would be equally effective - allowing users to build a new version of Semaphore with their changes and install it on a testing environment as they would a production version.

Acceptance Criteria

• Initial testing environment setup: less than 1 hour from start to finish
• Testing subsequent changes: less than 15 minutes per change
• Zero cost to contributor: no paid services required
• Real-world validation: @AleksandarCole will serve as our litmus test - he should be able to contribute based solely on our documentation
• Implementation timeline: completion within one week (setup and tested workflow)

Next Steps

Assigning to @VeljkoMaksimovic to collaborate with the team on mapping out additional implementation details.

---

@radwo - Please share any updates on the scaffold approach. We're interested in making this path available as well.

[AleksandarCole]

Closing discussion. Issue is logged and added in scope for the 1.3 release: #336