Not finding random refs

[boonew2]

I've been experimenting with this utility and from my testing so far it seems to be missing seemingly random references.

.launchdarkly/coderefs.yaml

aliases:
  - type: pascalcase

The codebase is largely C# and there is a file that has all of the flags accounted for as named constants converted to pascal case. I'm slightly modifying the names here, but the cs file has this in it:

public static ToggleKey Qa_Updates => new ToggleKey( nameof( Qa_Updates ) );
public static ToggleKey Authz => new ToggleKey( nameof( Authz ) );

and the flags in LD are called qa_updates and authz. The reference to authz is found correctly and reported, but qa_updates is not. There are other references across the codebase to Qa_Updates and Authz, but i'm focusing on this file specifically because it seemed like the most apples to apples comparison of mixed results.

Just to try and make sure the pascalcase alias was doing what i expected i re-implemented it with with a command alias:

 aliases:
  #- type: pascalcase
  - type: command
    command: python ./.launchdarkly/aliases.py
    timeout: 5

#! /usr/bin/env python
import sys,json
for flag_key in sys.stdin:
    flag_key = flag_key.strip()
    alias = '_'.join([word.capitalize() for word in flag_key.split('_')])
    aliases = json.dumps([alias])
    print(aliases)
    break

and got the exact same results with respect to those flags. Output from running the tool:

INFO: 2023/09/27 15:57:28 coderefs.go:27: absolute directory path: REDACTED
INFO: 2023/09/27 15:57:28 git.go:48: git branch: REDACTED
INFO: 2023/09/27 15:57:47 coderefs.go:148: sending 1090 code references across 909 flags and 331 files to LaunchDarkly for project(s): [ default]
INFO: 2023/09/27 15:57:48 coderefs.go:182: checking if 869 flags without references were removed in the last 10 commits for project: default
INFO: 2023/09/27 15:57:48 coderefs.go:187: found 0 removed flags
INFO: 2023/09/27 15:57:48 coderefs.go:199: attempting to prune old code reference data from LaunchDarkly
WARNING: 2023/09/27 15:57:48 coderefs.go:202: unable to retrieve branch list from remote, skipping code reference pruning: authentication required

[jazanne]

@boonew2 thanks for including all of this info

our alias tool uses https://github.com/iancoleman/strcase under the hood, and would convert a flag like qa_updates to QaUpdates - removing the underscore that you have in your code.

I'm not sure why you're not seeing the aliases from the custom command - i added a test cases for both of the situations you describe and the aliases appear to be generated correctly

https://github.com/launchdarkly/ld-find-code-refs/pull/391/files

Can you share with me how you're running the tool?

[boonew2]

Thanks for the quick response! I haven't plumbed it into our ci process yet since I'm just testing right now so i'm just calling it ad hoc from my computer. The full coderefs file looks like this:

---
projKey: default
contextLines: 2
repoName: REDACTED
repoUrl: https://github.com/REDACTED/REDACTED
repoType: github

ignoreServiceErrors: true

aliases:
  #- type: pascalcase
  - type: command
    command: python ./.launchdarkly/aliases.py
    timeout: 5

and from powershell i just have:

& 'C:\temp\ld-find-code-refs.exe' --accessToken "REDACTED" --dir C:\path\to\repo

[boonew2]

Hmm i copied the one cs file to a fresh repo along with the .launchdarkly folder and it worked as expected there. Found 2 code refs:

INFO: 2023/09/29 09:00:25 coderefs.go:27: absolute directory path: C:\temp\ld-repro
INFO: 2023/09/29 09:00:25 git.go:48: git branch: develop
INFO: 2023/09/29 09:01:02 coderefs.go:139: dry run found 2 code references across 912 flags and 1 files
INFO: 2023/09/29 09:01:02 coderefs.go:182: checking if 910 flags without references were removed in the last 10 commits for project: default
INFO: 2023/09/29 09:01:02 coderefs.go:187: found 0 removed flags

File count isn't the number checked but the number of files that had refs.

~It did make me notice the file count in the logs. The output from the actual repo noted 331 files checked.. but there are 2412 in that repository. I did add an .ldignore that lists a single file and it seems like the ld-find-code-refs tool ignores the .launchdarkly folder automatically which makes sense, but that would only account for a handful of files being different on the total count. The 2412 count was found with git ls-files so it should be taking into account the .gitignore auto exclusions. File count being very wrong is definitely weird, but since I'm seeing the inconsistent found refs within a single file i'm not sure it is my only problem~

[boonew2]

I added an --outputDir to the dryrun and found something telling. It actually has the refs in the csv, but they aren't bubbling up to the site when I view Code References for the flag.

[jazanne]

I added an --outputDir to the dryrun and found something telling. It actually has the refs in the csv, but they aren't bubbling up to the site when I view Code References for the flag.

that's good to know - are you sure when you're looking at the code references tab that you have ?branch=develop in the url? Otherwise it will only show the code references that are associated with the default branch (usually main or master)

[boonew2]

I got bit by that default branch filter originally, but caught that mistake before i ran here for help. I am definitely looking at the correct branch now and the expected refs are not there 🤔

[jazanne]

I got bit by that default branch filter originally, but caught that mistake before i ran here for help. I am definitely looking at the correct branch now and the expected refs are not there 🤔

ok i think i know what's up - sometimes we don't save new data if code refs runs on an existing SHA - can you try adding a new commit (can be empty) and then rerunning the tool and see if the refs show up in the UI?

[boonew2]

Yep that was it! I ran it earlier without the command alias in play and hadn't committed since then. Thanks a ton; i'll close out the issue. Out of curiosity was that pitfall documented anywhere that I should have seen it?

[jazanne]

Out of curiosity was that pitfall documented anywhere that I should have seen it?

I don't think it's mentioned in external documentation, it's just an internal quirk. Because of how code refs runs in CI, it's not usually an issue that people run into, just something that comes up when testing implementation/configuration like you were doing