Use a schema for message validation and description

[yeraydavidrodriguez]

When the issue #24 is merged, we will have JTD schema validation for the message body:

interface CommitBodyMetaData {
  job_number?: number
  job_commit?: string
}

interface CommitBodyData {
  namespace: 'git-queue.commit-body'
  version: number
  metadata: CommitBodyMetaData
  payload: string
}

const CommitBodySchema: JTDSchemaType<CommitBodyData> = {
  properties: {
    namespace: {enum: ['git-queue.commit-body']},
    version: {type: 'int32'},
    payload: {type: 'string'},
    metadata: {
      optionalProperties: {
        job_number: {type: 'int32'},
        job_commit: {type: 'string'}
      },
      additionalProperties: true
    }
  },
  additionalProperties: true
}

This allows us to have an expressive description of the commit body, and make validations and parsings more robust and simple.

This methodology should be extended to the commit subject, that will store the queue message.

[josecelano]

After releasing the v1-beta version I have been trying to update our two demo projects:

• chinese-ideographs-website
• library-consumer

I have problems in both cases because:

1. The queue name rules have changed. Library Update [library-aaa] is not a valid name anymore.
2. Some commit subjects require now a job id, which is not present for the old queue commits.

Even if I rename the queue we still have a broken workflow because the queue processes old commits too.

Broken workflows:

• Queue name not valid: Library Update [library-aaa]. Only lowercase letters (a-z), dash and white space are allowed, 30 characters max. Link.
• Missing job ID in commit subject: 📝✅: library-update: job.ref.df13e75c4835208ae64c2b383038709560b753c7. Link.

The problem is we have two versions of the queue in the same branch. Since we still have a beta version I would suggest removing previous queue commits from both projects. We were already considering this problem with this issue for future versions.

On the other hand, I think we should not process all queue commits. We should not get the error "Missing job ID in commit subject" because the commit does not belong to the new queue. But anyway, knowing which queue the commit belongs to depends on parsing the subject, so we still need to get the version of the queue to correctly extract the queue name.

cc @da2ce7 @yeraydavidrodriguez

[da2ce7]

Sounds like a job for https://gitlab.com/esr/reposurgeon
This allows for a git-to-git conversion, where you can write rules for replacing or editing commits, including their messages.