Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dependabot-script/custom commit users #317

Closed
yeikel opened this issue Feb 28, 2023 · 6 comments
Closed

Add support for dependabot-script/custom commit users #317

yeikel opened this issue Feb 28, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@yeikel
Copy link
Contributor

yeikel commented Feb 28, 2023

I am currently running dependabot-script in a private GHE instance to generate pull requests for my projects

I would like to leverage this project but this check :

// Don't bother hitting the API if the PR author isn't Dependabot
if (pr.user.login !== DEPENDABOT_LOGIN) {
core.debug(`PR author '${pr.user.login}' is not Dependabot.`)
return false
}
core.debug('Verifying the Pull Request contents are from Dependabot')
const { data: commits } = await client.rest.pulls.listCommits({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: pr.number
})
const { commit, author } = commits[0]
if (author?.login !== DEPENDABOT_LOGIN) {
// TODO: Promote to setFailed
core.warning(
'It looks like this PR was not created by Dependabot, refusing to proceed.'
)
return false
}

Expects the sender of the PR to be 'dependabot[bot]' when that's not possible within my context

Would you be open to adding an optional configuration parameter to the action to allow customizing this value?

As a side note, most Action examples suggest this as an optimization :

if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}

I am willing to send a PR with the same

@yeikel yeikel added the enhancement New feature or request label Feb 28, 2023
@yeikel yeikel changed the title Add support for dependabot-script and custom users Add support for dependabot-script.custom users Feb 28, 2023
@yeikel yeikel changed the title Add support for dependabot-script.custom users Add support for dependabot-script/custom commit users Feb 28, 2023
@jeffwidman
Copy link
Member

Yes, that makes sense to make it configurable. Happy to accept a PR.

I don't understand the "optimization" suggestion, but a quick PR might make that easier to understand too? Feel free to send two PR's if they're not tied together...

@yeikel
Copy link
Contributor Author

yeikel commented Apr 5, 2023

Yes, that makes sense to make it configurable. Happy to accept a PR.

I don't understand the "optimization" suggestion, but a quick PR might make that easier to understand too? Feel free to send two PR's if they're not tied together...

What I meant with the "optimization" is that workflow execution can be stopped before it even starts using the filter above. Example :

- name: Greet dependabot
        if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }} // This step will only run if the user matches. The "echo" command won't run at all
        shell: echo "Hello dependabot!"

Given that, there is no need to have additional checks within the action code

It won't hurt, but it is not needed

@jeffwidman
Copy link
Member

Ah makes sense, sounds good to me!

@jeffwidman
Copy link
Member

Based on the discussion in #332 , what do you think about the idea of instead creating an option that simply enables/disables the internal code check?

That way advanced users can effectively say "I know what I'm doing, turn this off" and then control everything via their GitHub workflow conditions?

I just think that might be less constrictive to advanced users like yourself.

If you agree, rather than amending #331, why don't you create an alternative PR, that way if someone points out something I'm overlooking that means we still need to specify a custom user, we haven't lost that code...

@yeikel
Copy link
Contributor Author

yeikel commented Apr 7, 2023

Based on the discussion in #332 , what do you think about the idea of instead creating an option that simply enables/disables the internal code check?

That way advanced users can effectively say "I know what I'm doing, turn this off" and then control everything via their GitHub workflow conditions?

I just think that might be less constrictive to advanced users like yourself.

If you agree, rather than amending #331, why don't you create an alternative PR, that way if someone points out something I'm overlooking that means we still need to specify a custom user, we haven't lost that code...

That's fair. I'll work on that next

@jeffwidman
Copy link
Member

Fixed by #336

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants