take advantage of dependabot parse method

[climba03003]

Prerequisites

• [X] I have written a descriptive issue title
• [X] I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal

Can we take advantage of the official dependabot parse method which based on full commit message? https://github.com/dependabot/fetch-metadata/blob/a7c13a83a67acff9b107367e6e9f1cdf9a66e97f/src/dependabot/update_metadata.ts#L29-L67

export async function parse (commitMessage: string, branchName: string, mainBranch: string, lookup?: alertLookup, getScore?: scoreLookup): Promise<Array<updatedDependency>> {
  const bumpFragment = commitMessage.match(/^Bumps .* from (?<from>\d[^ ]*) to (?<to>\d[^ ]*)\.$/m)
  const yamlFragment = commitMessage.match(/^-{3}\n(?<dependencies>[\S|\s]*?)\n^\.{3}\n/m)
  const lookupFn = lookup ?? (() => Promise.resolve({ alertState: '', ghsaId: '', cvss: 0 }))
  const scoreFn = getScore ?? (() => Promise.resolve(0))

  if (yamlFragment?.groups && branchName.startsWith('dependabot')) {
    const data = YAML.parse(yamlFragment.groups.dependencies)

    // Since we are on the `dependabot` branch (9 letters), the 10th letter in the branch name is the delimiter
    const delim = branchName[10]
    const chunks = branchName.split(delim)
    const prev = bumpFragment?.groups?.from ?? ''
    const next = bumpFragment?.groups?.to ?? ''

    if (data['updated-dependencies']) {
      return await Promise.all(data['updated-dependencies'].map(async (dependency, index) => {
        const dirname = `/${chunks.slice(2, -1 * (1 + (dependency['dependency-name'].match(/\//g) || []).length)).join(delim) || ''}`
        const lastVersion = index === 0 ? prev : ''
        const nextVersion = index === 0 ? next : ''
        const updateType = dependency['update-type'] || calculateUpdateType(lastVersion, nextVersion)
        return {
          dependencyName: dependency['dependency-name'],
          dependencyType: dependency['dependency-type'],
          updateType: updateType,
          directory: dirname,
          packageEcosystem: chunks[1],
          targetBranch: mainBranch,
          prevVersion: lastVersion,
          newVersion: nextVersion,
          compatScore: await scoreFn(dependency['dependency-name'], lastVersion, nextVersion, chunks[1]),
          ...await lookupFn(dependency['dependency-name'], lastVersion, dirname)
        }
      }))
    }
  }

  return Promise.resolve([])
}

Or we can depends on the workflow after dependabot/fetch-metadata@v1

Motivation

Prevent custom logic which may break or not supported for multiple languages.

Example

No response

[climba03003]

Update-Type

The update-type is pretty strict forward to what we need. It contains version-update:semver-major, version-update:semver-minor, version-update:semver-patch and <empty string>.

<empty string> is exist only when the version is not exist on those package. For example, commit hash update.

Dependency-Type

It also allow us to specify which dependency-type should be automerge. For example, direct, indirect, all, production and development.

We may allow the use-case like automerge direct:production in minor, but direct:development in major.

[guilhermelimak]

After investigating this issue for a while I think we got a couple of options:

1- Get the fetch-metadata action output and use it on github-action-merge-dependabot action. This would be the ideal solution I think, but after searching for a while I wasn't able to find a way to use the output of a workflow as input for our action while having it as some sort of explicit dependency. The only way would be to access something like steps.<step-name>.outputs.dependency, which would depend on the user creating a workflow with a predetermined name (which could be configurable on our side) for it's fetch-metadata step. If we aren't able to use it on our action we could just instruct the users to create a workflow that runs the fetch-metadata action before this one and pass it's outputs as inputs but this is not ideal since it is a bit error prone and wouldn't be very intuitive. It would also be a breaking change since all users would have to change their workflows.

One other thing I noticed is the fetch-metadata action could maybe be used to replace github-action-merge-dependabot entirely (I'm not sure deprecating our action is desirable tho), it has some examples on it's readme like so: https://github.com/dependabot/fetch-metadata#enabling-auto-merge. I'm not entirely sure it would have 100% feature parity however so maybe it isn't a good fit.

2- Improve the logic we have on our code right now. I've looked at dependabot's code and got all the combinations for pull request titles it can create, we could write tests for each one of them and that should solve the issue, at least until dependabot changes something on their side. I think this would be the ideal approach if we can't find a good way to integrate fetch-metadata into our action. No breaking changes for the users and relatively straightforward.

3- Try to copy the fetch-metadata parse method to our action. I don't think that's interesting since it has it's own dependencies and we would still need to keep it updated manually and also adapt it to work with our code so I think we would be better off just improving our current logic instead

cc @simoneb

[simoneb]

Thanks for the summary:

1. this could work if we turned our action into a composite action, which should be fairly simple. see how the optic release automation action is done
2. compelling but too many changes to do and has some limitations, such as having to provide a PAT. we don't want that, so I'd exclude this option
3. yeah this would work but I'd really keep it as the last resort, we don't want to copy code. on the other hand, we could (if no other options are viable) ask them to expose that method.

I'd go with 1. if for any reason that's not an option, fallback to 3

[guilhermelimak]

I'll take a better look at the optic release action. That's probably the best way to do it.

About 2, I don't think I get the limitations/need for a token. Maybe I wasn't very clear but we would basically keep everything the same and just change the parsing code a bit to accommodate more PR titles so I don't think that would change anything for the users.

[simoneb]

ah yeah sorry, I had interpreted 2. as switching over to that action. 2 is also an option, overall changing our code to support all possible PR titles shouldn't be that difficult

[github-actions[bot]]

🎉 This issue has been resolved in version 3.4.0 🎉

The release is available on:

• GitHub release

Your optic bot 📦🚀