proposal: build identifier after modifiers about node-calver

[muratgozel]

Hey 👋, thanks for pointing this out. I think this is completely valid and under the scope of this library. Let's clarify a few things before making any effort. I remember there are auto-generated build identifiers and there could be user-specified build identifiers as you suggested. The library should cover both cases if you ask me. (Maybe by placing a config param to the inc method?) I'm open to ideas and would happily accept a PR for this. My only concern for this library is to keep the codebase dependency-free and clean, easy to understand. Have you considered how to implement such logic?

[busla]

Hey, sounds great 🙌🏼

Right, so this is probably a hybrid of some sort, between pre-release denotation and build-identifiers. I guess both could be implemented but perhaps start with build-ids.

I totally agree with keeping the the dep-free policy 🤌

I have just scrolled through the code briefly but as a first iteration the string could be passed as a config param, like you suggest.

In the meantime, I created this wrapper 😄

https://github.com/busla/calver-ci

[muratgozel]

Looking good!

Here is how it could work: An identifier property could be specified under options argument. If I set it to true, library generates the identifier. if i set it to a string, library directly chose that string as identifier by applying some validation like [a-z0-9A-Z_\-].

calver.inc(format, '2021.1.1.0', 'minor', { identifier: true })
// or
calver.inc(format, '2021.1.1.0', 'minor', { identifier: 'my-identifier' })

What do you think?

[busla]

That would fit the requirements. I guess the identifier would mostly be used as a passthrough from the build services but I'm sure that there are scenarios where you just want it to be generated.

Perhaps instead of boolean, a configuration object could be passed so the user can compose the identifer using known properties within the enviroment (e.g. git). That would also allow for other configs, like separator.

Example:

const options = {
  separator: '-',
  attributes: [
    {
      commitSha: {
        length: 7,
      },
    },
    {
      commitBranch: {
        maxLength: 10,
      },
    },
    {
      commitAuthor: {
        maxLength: 10,
      },
    },
    {
      random: {
        maxLength: 15,
      },
    },
  ],
};

[busla]

a simpler approach would be to offer templates for common providers, e.g. Github, Gitlab, since we have access to loads env variables already in the pipelines.

[muratgozel]

And those templates could be like { identifier: "[branch][hash:16]" } because some of us are already familiar with this approach:
https://github.com/webpack/loader-utils#interpolatename

All of the above makes sense! I think we can start with { identifier: "my-identifier" } (which I think is what you need primarily) and then expand it later to cover object type options. I would like to leave this issue open for future opinions. Send a PR please if you have time.

[busla]

ahh!

even better to use something conventional 🙌

will create a PR soon.