Better handle port number collisions between developer namespaces on a single instance

Open
#1,002 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
git
Domain
developer-experience, devtools

Research direction

Start by reviewing the port-collision scenarios involving Embedded Git, private developer namespaces, and System Default Settings. Compare the current behavior of shared ports, null ports, and exported enabled flags. Done means the team has selected and specified a concrete approach that prevents collisions without requiring manual per-branch service changes.

Written by the indexing model from the issue text.

Description

Say my team is developing a Health Connect production. We're using Embedded Git for source control, with each developer working on a private namespace on the same instance. The production includes some inbound services that have a port number.

Some options are:

  • use a shared set of system default settings defining the port number: then there are errors because services in different namespaces try to claim the same port number
  • leave the port numbers null: the production fails to start because of services missing port numbers
  • leave the port numbers null, and disable all the services except the ones you're currently working on: the "enabled" flag gets exported to source control, and incorrectly ends up deployed
  • leave the port numbers null, and use System Default Settings to disable all the services except the ones you're currently working on: it's a huge pain to manage all these system default settings and change them manually every time you switch branch to work on a different feature.

Let's brainstorm a better way to do this. Potentially a new feature in Embedded Git, or maybe there's a better way to handle this using existing product features.

Dominant language
ObjectScript
Stars
22
Forks
14
Avg merge
1d 9h
Merged PRs (30d)
5

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from intersystems/git-source-control

All issues in intersystems/git-source-control

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.