Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: build identifier after modifiers #11

Open
busla opened this issue Sep 10, 2022 · 7 comments
Open

proposal: build identifier after modifiers #11

busla opened this issue Sep 10, 2022 · 7 comments

Comments

@busla
Copy link

busla commented Sep 10, 2022

Great package, thanks for sharing 🙏🏼

I want to propose adding a build-identifier option that, if used, would be appended to a modifier. The identifier on previous versions would be ignored when determining next version, and would not affect the current version rolling logic.

This would also comply with semver conventions.

From semver:

Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

Example scenario

  • Calver format: yy.mm.dd.patch
  • Version on production: 22.9.10.0
  • git short sha: abcd123

A developer is working on the feature deployment branch fixing-stuff and determined version for the first feature deployment is 22.9.10.1-dev.0 accessible at https://fixing-stuff-abcd123.dev.company.com. There are several services that participate in the deployment, e.g. sentry, spinnaker, et.c.

A build identifier that would become part of of the deployment chain would simplify targeting regressions or broken deployments.

Example version using a build identifier: 22.9.10.1-dev.0+fixing-stuff-abcd123.

This would allow developers and QA to quickly target where problems were solved (or occurred) during the development phase since it has a human annotation to it 😄

I am up for creating a PR if this makes sense, otherwise I will concat the build identifer to the calver version.

@muratgozel
Copy link
Owner

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
Copy link
Author

busla commented Sep 10, 2022

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
Copy link
Owner

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
Copy link
Author

busla commented Sep 11, 2022

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
Copy link
Author

busla commented Sep 12, 2022

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
Copy link
Owner

muratgozel commented Sep 12, 2022

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
Copy link
Author

busla commented Sep 12, 2022

ahh!

even better to use something conventional 🙌

will create a PR soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants