Package name where the code is located

[kenhov]

Is it possible to get the package name the source is located when viewing the logentry page? We have divided our code into multiple repos, and we create a package for each repo. It would be useful to see which package/repo the source code is coming from.
One idea could be to add a parameter for the Github Org your repos are located, and create a direct link to the code in github. But I don't know if that is possible, since it seems like the github url to a codeline contains dynamic variables.

[kenhov]

You could actually make a search link with a combo of the github org and the path syntax. And you got the filepath in the sourcecode window.
https://github.com/search?q=org%[YOURGITHUBORG]+path%3A**%2F[FILEPATH]

[jongpie]

Hi @kenhov - just to make sure I'm following, it sounds like....

• You have multiple (2GP?) packages that you own + maintain + install in your orgs
• When an Apex class in one of your packages logs something (using Nebula Logger), you'd like the log entry page to show which package or repo contains that Apex class. Some examples:
  • Package A contains SomeClass --> when SomeClass logs, the generated LogEntry__c record should somehow indicate that SomeClass is part of Package A
  • Package B contains AnotherClass --> same thing, when AnotherClass logs, the generated LogEntry__c record should somehow indicate that AnotherClass is part of Package B

Let me know if my understanding is correct. If so, I think it will be difficult to accurately track/display the file's location within GitHub, but I think it might be feasible to instead track details about the package itself, such as...

• Package name + package ID
• Package version name + package version ID

If this can be done, would this give you enough info?

[kenhov]

We have unmanaged packages that we create and install in our org. The examples are exactly what I mean. If possible to get package name in the logging, that would be amazing :-)

[jamessimone]

@kenhov what kind of packages is your codebase broken up into?

One possibility would be the addition of an overload to LogEntryEventBuilder - something like setPackageId (which you would provide via Packaging.getCurrentPackageId. However, that method is itself reliant upon you using a compliant packaging type (last we checked, 1GP packages don't actually work when calling that method).

There's some additional complexity here due to needing to call the Tooling API to actually fetch the package information, so it'd help to know up-front if that packaging method is compliant with the kind of packages you're using, or if you'd otherwise have some way of providing that info at a per entry or per log level.