Cascade author details to Azure commit

[acraven]

I'm not expecting this to be merged, it's just an opener before I spent time learning how to write Ruby/rspec tests.

Having tried passing to author_details to PullRequestCreator I'm still getting a null author email in the Azure DevOps repo, which causes an exception elsewhere in dependabot. The changes are where I think the gaps are.

I can confirm that if I call the Azure API directly to create a commit, the commit author defaults to those relating to the access token. The author fields can be completely or partially supplied and the API fills in as best it can.

It doesn't seem that there is an email associated with the System.AccessToken pipeline variable. Ultimately this appears to be causing my problem.

[acraven]

@greysteil after trying what you suggested, I'm still having problems. Please could you take a look and see what you think. If you think there's a genuine gap, then I can look at adding some tests.

[chris5287]

Does the author_details structure match what’s expected by the REST api? https://docs.microsoft.com/en-us/rest/api/azure/devops/git/pushes/create?view=azure-devops-rest-5.0#gituserdate

Also make sure you check if author_details has a value, as we don’t pass this around ourselves.

[greysteil]

I've cleaned this up and think it should be good to go now. @acraven can you test it? You'll want to set dependabot-script to point to this branch (so the Gemfile will be something like gem "dependabot-omnibus", git: "https://github.com/acraven/dependabot-core", branch: "azure-author-details".

[acraven]

@greysteil I added some thoughts for tests in the last push, but looks like you've covered @chris5287 's concerns. I hadn't realised you were jumping in; it's fine, I can just remove the empty tests unless you think there's value in implementing them.

[acraven]

@greysteil That's a nice workflow for integration testing. I haven't tested with dependabot-script itself, but my own equivalent now works. Thanks very much for your help (and @chris5287 too).

I had to create another repo that hadn't previously been infected with an empty author.email. Even having deleted the remote and local branches of the rogue PR (without author.email) dependabot failed.

I'm happy if you want to remove the empty tests and accept the PR, but please squash merge if you can as my commits look untidy.

[greysteil]

Awesome - I'll take this from here. Can I ask you to sign a doc (attached) that transfers the IP from this contribution to Dependabot? Sorry it's a pain - we need it because we're planning to change the license on this repo (to one with the same intention that's a bit tighter).

Dependabot IP Letter - Andrew Craven.pdf

If you can email the signed form to support@dependabot.com that would be awesome. Electronic signature is fine.

[acraven]

@greysteil Will sort out the doc. In the meantime, please hold off merging, which I guess you will without the signed doc. I'm now running my script in Azure using this PR's Gems but it's not creating the PRs. I'm seeing new branches with commits and these are populated with author name and email as per the update.rb script.

It created the PRs when I ran locally. I wonder if the committer email being blank is now a problem.

Investigating...

[acraven]

Right, this doesn't seem solvable by you or me, the PR API is returning 403 "message":"TF401027: You need the Git ''PullRequestContribute''. I'll ask someone with creds to add this to the principal running the pipelines.

I guess this means the PR is okay, but I need to parse the response better (currently just pulling out the PR number)

[acraven]

@greysteil you should have IP transfer in your inbox.

I created by own Azure DevOps org to test this - I found I had to add not only Contribute to pull requests to Project Collection Build Service, but also Create branch. PRs were created successfully once this was done.