This also relocates the create-changesets job to the PR-lint step so that in the case where dependabot does open the PR, that step is run before it's linted.

Closes #2320

• As the test (or report-coverage) is a required step in our pipeline - I'm not entirely convinced this will work for dependabot, unless we make the coverage report not required.
• I believe the validate-changeset job would need to be dependant on create-changeset job for this to be reliable.
• The create-changeset job will require elevated permissions to write the commit.

---

I'd personally revert and re-evaluate our overall strategy.

There are security considerations to be had when elevating permissions and we should understands the risks fully before doing so IMO.

to prevent potentially compromised dependencies from capturing secrets referenced in your workflows.

• As the test (or report-coverage) is a required step in our pipeline - I'm not entirely convinced this will work for dependabot, unless we make the coverage report not required.

The rationale here is that we don't need to report coverage for dependabot PRs given an upgrade in a dependency would not result in a difference in the coverage, there is nothing in the workflows to suggest that the test/report-coverage step is required.

• I believe the validate-changeset job would need to be dependant on create-changeset job for this to be reliable.
• The create-changeset job will require elevated permissions to write the commit.

Consider the two branches:

1. if the PR is not created by dependabot, then the create-changeset job will not be run, and thus validate-changeset will only fail if the creator of that PR has not added a changeset, which is the desired outcome.

2. if the PR was created by dependabot, then create-changeset job runs, if it fails, the validate-changeset will fail, this is desirable because there would be a need for a changeset, otherwise the validate-changeset passes and all is well.

I'd personally revert and re-evaluate our overall strategy.

There are security considerations to be had when elevating permissions and we should understands the risks fully before doing so IMO.

to prevent potentially compromised dependencies from capturing secrets referenced in your workflows.

My understanding when adding the create-changeset job was that no elevated permissions were given to dependabot in as the commit is done by the github bot and not dependabot, but that could be wrong. We could consider using the @fuel-service-user to create the changesets for dependency upgrades if this is a concern, otherwise we could forgo changesets for dependency upgrades.

Interested to hear others thoughts @nedsalk @Torres-ssf @arboleya @Dhaiwat10 @danielbate

there is nothing in the workflows to suggest that the test/report-coverage step is required.

This is set in the repository settings rather than in the workflow. @arboleya can set this / change it to report-coverage if we wanted. But test is currently a required stage.

I think we should be adding changesets for dependabot PRs, should these introduce issues it'll make them easier to patch.

My concern is that if the perms were not correct for coverage reporting, I'd assume changeset creation would be similar. Testing @fuel-service-user is a good move but we should do this sooner rather than later, and if it proves unsuccessful we should revert #2295 and test in isolation.

@maschad I won't be able to follow up on this soon. I suggest you guys do huddle/call about it to be more productive and reach a consensus. If the revert is the solution for now, so be it. Otherwise, whatever fixes the problem, fix the problem. We need to get those workflows green again.

cc @petertonysmith94 @nedsalk @Torres-ssf @danielbate

I realize that we may have overcomplicated things. We can simply change the workflow to have write permissions and then only run this job when it is dependabot acting , I took inspiration from the common dependabot operations

Has this been tested on a fork?

Has this been tested on a fork?

Unfortunately that's not possible (with good reason) as you can imagine the implications of allowing someone who doesn't have write permissions to a repository but could configure GitHub Actions to respond to do so.

Happy to approve 🍏 Can't see anything that could block the CI like the previous iterations.

Still skeptical if this will work, as I believe dependabot will not be able to request the permissions that are required (akin to externals forks).

Still skeptical if this will work, as I believe dependabot will not be able to request the permissions that are required (akin to externals forks).

@petertonysmith94 that's valid. It's not exactly clear in the Github documentation, suggests we can use the permissions key in our workflow to increase the access for the GITHUB_TOKEN. What we can do to be more certain is add a dependabot secret as you had suggested to be certain.

Coverage Report:

Lines	Branches	Functions	Statements
46.37%(+0%)	39.55%(+0%)	43.6%(+0%)	46.2%(+0%)

Changed Files:

Coverage values did not change👌.