Getting systematically ,"",false,0,0,0,0 output

[eboukandoura]

Hi,

I've set up a new GH action workflow that is using peter-murray/inactive-users-action@v1 and actions/upload-artifact@v2 actions.

I've set it up with a personal access token that has the required permissions and set it up with the organization.

This seems to work as the execution of this workflow will generate a csv file which is made of as many rows as members in this organization (only members, not outside collaborators though), but each and every row systematically output this information

<actual user name> ,"",false,0,0,0,0

This is surprising since quite a few of these users have contributed over the last 90 days.

Would you know of anything specific I should check?

Thanks,

Emmanuel

[peter-murray]

Can you possibly take a look at the JSON file that it is generating, it will register that as an output.

It could be related to permissions on the PAT token, as you can have access to the organization for instance and see the members, but not be able to access one or more of the other endpoints that it is using to build up the dataset.

Can you possibly share the permissions that are set on the token and share them here?

[eboukandoura]

Hi Peter,

Thanks for your reply. I'll to see how I can access the json file, but for the time being here is a screenshot of the permissions set for the PAT:

How does it look to you?

[peter-murray]

The permissions look correct. I am wondering if there is something more to the access permissions required, as I have ownership of the enterprise and org and no easy way to strip these for testing....

[peter-murray]

I have created a branch called logging which has a modification that will print out the results of the queries and report back when it fails to load any results (this can be valid in the case of no PRs or Issues for instance).

If you update your version of the action from v1 to logging and run it again it will print out the users in the results it is getting back for the time frame specified for commits, issue comments and pull request comments as it is processing the repositories.

Also it will print a warning now when it fails to pull back any results, keeping in mind this can be valid if there are no object associated, but if excessive it may reveal a permissions issue.

[eboukandoura]

Hi @peter-murray,

Many thanks for this.

I've updated the workflow to use the logging version of the action and I can confirm that the logs now mention user activity

Building repository activity for: XXX/YYY... identified commit activity for 2 users in repository XXX/YYY identified issue comment activity for 0 users in repository XXX/YYY identified pull request comment activity for 2 users in repository XXX/YYY completed.

However the csv and the json still look similar and don't seem to reflect any user activity.

Could it be because of the way I'm using the action?

`jobs: Run_report: runs-on: ubuntu-latest steps: - name: Checkout Action uses: actions/checkout@v2

- name: Analyze User Activity
  id: analyze_user_activity
  uses: peter-murray/inactive-users-action@logging
  with:
    token: ${{ secrets.EBO_TOKEN }}
    organization: XXX (redacted)
    
- name: Save User Activity Report
  uses: actions/upload-artifact@v2
  with:
    name: reports
    path: |
      ${{ steps.analyze_user_activity.outputs.report_csv }}
      
- name: Save User Activity json
  uses: actions/upload-artifact@v2
  with:
    name: reports2
    path: |
      ${{ steps.analyze_user_activity.outputs.report_json }}`

[peter-murray]

If you are seeing the numbers for activity on users, then data is definitely coming back on at least something and you should be seeing at least some users with activity in those cases. It is the data that is converted into a rollup that is output as the JSON and CSV files.

Did you see a lot of warning messages or outputs where there are a lot of 0 users in repository logged? If so are these expected based on activity you know is occurring in those? It becomes a bit tricky here to further dial in on the problem without being able to further link together the expected disparity you are seeing.

By default this should be looking at the last 30 days of activity based on the workflow you are using there as that is the default. Maybe you could try to increase that window of activity, but based on your feedback you seem to be getting results that you have already correlated to the user's activity you expect to see?

It might be worth us have a quick call on this to possibly further diagnose and share some more information in a secure way, if this is needed let Maya know and we can set up a call.

[eboukandoura]

Dear @peter-murray ,

Sorry for the delay in getting back to you. As I was off most of last week I had to play catch up at the start of this week ;)

I could not see any occurrence of the warning message in the logs of this run (nor on any since I switched to the logging version of this action.

More than happy to jump on a call and discuss it further. What day/time would work for you? Worth sharing that I'm based in the Netherlands (hence currently GMT+1).

Cheers,

Emmanuel

[peter-murray]

Send me an email at [email protected] with some availability and we can schedule from there.

[peter-murray]

Hi 👋 @eboukandoura,

I have applied some extra debug/outputs and as I was walking through the code to add them identified a potential issue that might be causing this mapping failure.

On the logging branch of the action, there is a new debug input that when set to true will dump out the JavaScript objects that contain the complete findings from the API calls and the mapping data for that converted into a user central object view.

If you add the above input in your workflow then after it executes, there will be two collapsed sections in the action log;

We can use that to further investigate if need be, but I think the issue might have been around the email addresses of the users when I was building the user centric map, so fingers crossed it was fixed when I corrected that in the changes.

[eboukandoura]

Good evening @peter-murray,

Thanks for the update. I've run the workflow again using the action from the logging branch

name: Analyze User Activity
      id: analyze_user_activity
      uses: peter-murray/inactive-users-action@logging

However whilst the "user activity" is still logging similar type of content, the content of the saved report hasn't improved.

I've also enabled the debug:true flag and here is the output

:arrow_down_small:Organization Repository Activity Data { "VanOord/<name of repo #1>": {}, "VanOord/<name of repo #1>": {}, .... "VanOord/<name of repo #N>": {}, }

:arrow_down_small:User Activity Map {}

Looks like there's nothing to be dumped out of the JavaScript objects at this stage of the execution.

Anything I could do to help you troubleshoot this?

Cheers,

Emmanuel

[peter-murray]

If all those objects are empty, then the logs above from the action execution would be reporting back zeros for all the activity, which would point to permissions/visibility of the user for the PAT token...

If you could dump the full logs from a run into a private gist and share with me that content I can try to look over the run and see where the problem might be?

[RyanFrench]

I came across this same issue. I believe it's because the GitHub APIs are not case sensitive, however, when populating the data map here using the fullName that is pulled from GitHub as an index means it is case sensitive.