Auto suggest version label on graph deploy to be next semver patch

[schmidsi]

It is very annoying to always enter a new version label, especially when following semver. Can't we just suggest the next patch version?

• First deploy it would suggest: v0.0.1
• Next deploy it would suggest: v0.0.2
• If I manually changed the version to: v1.0.0 suggest next: `v1.0.1
  Thoughts?

[schmidsi]

yarn deploy               
yarn run v1.22.19
$ graph deploy --node https://api.studio.thegraph.com/deploy/ cryptopunks-aggregations-test
Which version label to use? (e.g. "v0.0.1"): v0.0.3

[saihaj]

is there a way we can query index-node otherwise we can add to JSON-RPC endpoint

[schmidsi]

Maybe to have some progress before an API is available, we could just keep track of the latest version in package.json?

[saihaj]

do users update package.json versions with subgraphs? I personally don't.

[schmidsi]

Me neither, but we could automate it?

[schmidsi]

Like when I type graph deploy, the CLI checks package.json for the version key and suggests to increment the patch version. If the user just hits enter, the CLI would update the version in package.json and also send that version to the studio endpoint.

[schmidsi]

This is some code that I saw in the wild from @GundamDweeb :

const executeStudioDeployWithVersionIncrement = async (subgraphName, version) => {
  let [major, minor, patch] = version
      .split('.')
  const cmd = `yarn deploy-studio ${subgraphName} -l=${major}.${minor}.${ parseInt(patch)}`
  let stderr =  await executeComanndErrorReturn(cmd)
  if(stderr){
    if(stderr.includes("Version label already exists")){
      console.log(`Stuido version for ${subgraphName} exists - attempting deploy with version - ${major}.${minor}.${parseInt(patch)+1}`)
      return executeStudioDeployWithVersionIncrement(subgraphName, `${major}.${minor}.${parseInt(patch)+1}`)
    }
  }
}

[GundamDweeb]

The "wild" he says 😂 Happy to add more context as this function is part of the larger build & deploy scripts for one or more chains that we use in the BuildersDAO.

Some updates I would include here are:

1. When patch gets to 10 (or some other number), increase minor by 1 and make patch 0. Same for minor to major.
2. This does not deal with the alpha numeric (eg v1.0.1a) - it could handle it by ignoring the a and keeping it numeric
3. This is devilishly slow if you for instance pass in v0.0.1 and its on v0.0.8 - the process of attempting a deploy takes a while, and this would happen 8 times before getting to v0.0.9

[schmidsi]

@saihaj I think there was some progress on this, no?