feat: add ability to detect current project #242

danudey · 2025-09-29T18:26:25Z

The Semaphore CLI tool has the ability to detect the current project, but there are a few caveats:

It relies on the assumption that origin is the upstream remote; this is not a safe assumption because when creating a fork the gh cli tool will rename the upstream remote to upstream and set the new fork to be origin.
This functionality is never exposed to the user directly

This means that if a user needs the current project ID (e.g. to trigger a pipeline via the API), they must get the list of all remote URLs themselves, get the list of all projects themselves, find a match between the two, and then call sem get project <project name> to get the project's ID.

This PR does a few things (updated from the previous implementation):

First, we add a new function getAllGitRemotesAndProjects(), which does the following:

Gets all the configured git remotes and their URLs via git config
Gets all the configured projects in the current Semaphore context
Produces a list of (remoteName, remoteURL, semaphoreProject) where the project URL matches the remote URL; in other words, every configured remote for which a configured project exists.

Secondly, we also add a small helper function, getGitHubBaseRemoteName(), which checks the repository's git configuration via git config to see if the user has run gh repo set-default to choose a default remote.

Thirdly, we refactor InferProject() to call getAllGitRemotesAndProjects() and then choose one of the results with the following detection logic:

If we only have one result, use that
If the user has used gh repo set-default and that remote is in the list, use that
If the results include an origin repo, use that; if not but there's an upstream repo, use that
If the multiple non-default, non-origin, non-upstream remotes all have the same URL, return the project matching that URL
At this point, we have multiple remotes with non-standard remote names and different URLs, all of which have different projects configured for them; we can't guess a correct project so give up.

The original InferProject() simply chose the origin remote and used that, so this new logic will cover those cases as well, and thus shouldn't cause issues with the rest of the codebase.

Lastly, we add a new sem get current_project (alias sem get cur) which simply prints out the project's metadata:

sem get current_project
04ebc08e-437f-45e0-9abd-b5d1d66bb126 projectname git@github.com:thisorg/project.git

Originally I was planning on highlighting the current project when a user did sem get project without an argument, but that ended up feeling messier than just having a separate command for it which a user could parse.

Edit: Added a --json flag to current_project to format the output as JSON (which includes far more data).

Edit 2: Bumped golang version from 1.20 to 1.21 to get the slices package (should go to 1.25 IMHO but this is a minimal change), and added -buildvcs=false to work around git permissions warnings in docker container when running make build

Edit 3: Completely rewrote almost everything into a vastly simplified and yet more complicated implementation.

hamir-suspect · 2025-10-10T12:31:29Z

Respect remote order when inferring project — `cmd/utils/project.go:45-63`

With the new InferProject()/getProjectFromUrls() flow we now pick the first project returned by ListProjects() whose URL matches any of the repository remotes (slices.Contains(urls, p.Spec.Repository.Url)).

When a repo has multiple remotes that each point to different Semaphore projects (e.g. origin for the main project and staging for an internal clone), the API’s ordering determines which project we pick.

There is no guarantee that the API returns the origin project (or the user’s intended default) before the others, so we can end up targeting the wrong project for every sem get … command that relies on InferProjectName(), as well as for the new current_project command.

We should iterate in remote order (preferably checking origin first) instead of project-order to avoid returning the wrong project.

Makefile

In previous implementations, we would infer the current project by getting a list of all remote URLs and then choosing the first project that matched one of them, which isn't necessarily the correct one. In this commit, we add some logic to try to make the best choice possible, using the following logic: 1. Get a list of all remotes, with their names and URLs 2. Get a list of all projects from Semaphore 3. Make a list of all remotes where there is a project configured for that remote's URL (so all remotes wihch have an associated project in Semaphore) Once we have that, we choose one based on the following logic: 1. If there's only one, choose that 2. If the user has run `gh repo set-default` in this repository, use the repository they chose at that point. 3. If there's one named "origin" choose that one. This is git's default remote name when you clone. 4. If there's one named "upstream" choose that one. This is what the `gh` CLI will rename your "origin" repo to when you create a fork for a new PR. 5. If there's more than one remote but they all have the same URL, then just use whichever project matches that URL. 6. If we still can't decide, print an error to the user; they're probably doing something weird.

danudey · 2025-10-22T22:40:39Z

@hamir-suspect Alright, two updates:

I put the buildvcs param back and made another change to test; it does require the docker container to be rebuilt, though, which docker compose doesn't seem to want to do automatically. I think docker-compose build will do this though?
I rewrote almost everything else I wrote to be both more and less complicated, but to be a little smarter about what project it picks if there's more than one.

One decision I'd like input on: currently, if the user has run gh repo set-default in their repository to choose a default remote for creating PRs against, we infer that remote to be the current project. This would only be a breaking change if:

The user had an origin remote pointing to a repo associated with semaphore project A; and
Another remote pointing to a repo associated with a different semaphore project B which they had chosen as their default via gh repo set-default.

In other words, they're creating PRs against project B but origin points to project A.

We can flip this logic so that if they have a matching origin or upstream repo we use that (which guarantees we'd match the old logic if applicable), and then we fall back to the gh-configured default repo. For me the current behavior makes sense, but y'all have more experience with users so I'm happy to flip it if it makes more sense this way.

hamir-suspect · 2025-10-29T15:02:11Z

Hey @danudey totally agree with the current logic—keeping the gh repo set-default remote as the first choice. Just a small nit-pick and we can merge this

cmd/get.go

Co-authored-by: Amir Hasanbasic <43892661+hamir-suspect@users.noreply.github.com>

loadez · 2026-01-08T18:31:25Z

cmd/utils/project.go

+			return &gitRemote, nil
+		}
+	}
+	return &GitRemote{}, fmt.Errorf("no remote matching %s found in remote list")


You are missing the parameter for the fmt.Errorf, I think it would be remoteNameOrUrl

loadez · 2026-01-08T18:33:27Z

cmd/utils/project.go

+	}
+
+	fields := strings.Fields(lines[0])
+	remoteName := strings.Split(fields[0], ".")[1]


You are accessing the position 1 of the array without checking the length of the array. Please do the same thing you did with line (split+len)

loadez · 2026-01-08T18:34:11Z

cmd/utils/project.go

+	for _, line := range lines {
+		fields := strings.Fields(line)
+		keyFields := strings.Split(line, ".")
+		remoteName := keyFields[1]


Here we have the same potential problem as well, please add a length check.

loadez · 2026-01-08T18:39:22Z

cmd/utils/project.go

+	// If we only got one remote with a configured project, return it;
+	// alternately, if we got multiple, return the alphabetically first
+	// one.
+	if len(gitRemotes) == 1 {
+		return gitRemotes[0].Project, nil
+	}


Can you explain to me this comment please, how is the gitRemotes sorted?

loadez · 2026-01-08T18:40:01Z

cmd/utils/project.go

+	lines := strings.Split(strings.TrimSpace(string(out)), "\n")
+
+	projectClient := client.NewProjectV1AlphaApi()
+	projects, err := projectClient.ListProjects()


You are missing an error check here

loadez · 2026-01-08T18:46:03Z

cmd/utils/project.go

+
+type GitRemoteList []GitRemote
+
+func (grl GitRemoteList) Contains(remoteNameOrUrl string) bool {


I couldn't find anywhere where this method is used, if this is a leftover please remove or tell where it is/will be used.

loadez · 2026-01-08T18:47:31Z

cmd/get.go

+Long: `Determine the Semaphore project associated with this repository.
+
+	Resolution order:
+	1. A remote selected by 'gh repo set-default', if present.
+	2. The 'origin' remote, when configured.
+	3. The 'upstream' remote, when configured.
+	4. Any remaining remote whose URL is shared by all candidates.
+	5. An explicit error when multiple distinct URLs remain.`,


nit: this long string has whitespaces before each line which I think wasn't intentional, please correct me if I'm wrong.

loadez · 2026-01-08T18:49:17Z

cmd/utils/project.go

+		fields := strings.Fields(line)
+		keyFields := strings.Split(line, ".")
+		remoteName := keyFields[1]
+		url := fields[1]


To improve readability and validation we could extract this to a function and do some more validation of the expected formatting of the string that we expect.

But I'm okay with maintaining this style and just fixing the length check.

loadez · 2026-01-08T18:51:43Z

cmd/get.go

+			utils.Check(err)
+			fmt.Println(string(jsonBody))
+		} else {
+			fmt.Println(project.Metadata.Id, project.Metadata.Name, project.Spec.Repository.Url)


nit: we could format this in some way that is easy to split the string

loadez · 2026-01-08T18:56:47Z

cmd/utils/project.go

+	for _, line := range lines {
+		fields := strings.Fields(line)
+		keyFields := strings.Split(line, ".")
+		remoteName := keyFields[1]
+		url := fields[1]
+
+		for _, proj := range projects.Projects {
+			if proj.Spec.Repository.Url == url {
+				remotes = append(remotes, GitRemote{Name: remoteName, URL: url, Project: proj})
+				break
+			}
+		}
+
+	}


This part of the code is O(n*m) because of the nested loops, you could use maps to improve the complexity to O(n+m).

I think this is not that much about performance but for readability. But I can see some cases that a few ms can compound in the long run.

loadez · 2026-01-08T18:59:23Z

Hey @danudey, I left some comments of things that we need to fix. We can discuss the nit picks and fixes that aren't critical in your view.

Also thank you for submitting a PR, few free to tag me with any question that you have.

danudey added 7 commits September 29, 2025 11:26

Add two ways to get the current project

58381a0

More refactoring

20337e4

Remove (active) from project list; fix InferProject()

8e81584

Better error message

dd35574

Add --json flag to current_project

01074b3

Bump minimum go version to 1.21 (for slices)

5e93783

Add -buildvcs=false to build

155bbec

hamir-suspect self-requested a review October 2, 2025 09:46

hamir-suspect requested changes Oct 10, 2025

View reviewed changes

Makefile Outdated Show resolved Hide resolved

danudey added 3 commits October 22, 2025 12:57

Remove -buildvcs=false, add git safe.directory

e2a6713

Remove now-dead code

ddb9878

danudey requested a review from hamir-suspect October 22, 2025 22:40

hamir-suspect approved these changes Oct 29, 2025

View reviewed changes

hamir-suspect requested changes Oct 29, 2025

View reviewed changes

cmd/get.go Outdated Show resolved Hide resolved

hamir-suspect reviewed Oct 29, 2025

View reviewed changes

cmd/get.go Outdated Show resolved Hide resolved

Update cmd/get.go

5adc57e

Co-authored-by: Amir Hasanbasic <43892661+hamir-suspect@users.noreply.github.com>

danudey requested a review from hamir-suspect October 31, 2025 18:10

loadez reviewed Jan 8, 2026

View reviewed changes


		type GitRemoteList []GitRemote

		func (grl GitRemoteList) Contains(remoteNameOrUrl string) bool {

feat: add ability to detect current project #242

Are you sure you want to change the base?

feat: add ability to detect current project #242

Uh oh!

Conversation

danudey commented Sep 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hamir-suspect commented Oct 10, 2025

Respect remote order when inferring project — cmd/utils/project.go:45-63

Uh oh!

Uh oh!

danudey commented Oct 22, 2025

Uh oh!

hamir-suspect commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

loadez commented Jan 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

danudey commented Sep 29, 2025 •

edited

Loading

Respect remote order when inferring project — `cmd/utils/project.go:45-63`

hamir-suspect commented Oct 29, 2025 •

edited

Loading