concourse / semver-resource

automated semantic version bumping
Apache License 2.0
96 stars 105 forks source link

"pre" does not like a period in the prefix #91

Open ccrvincent opened 5 years ago

ccrvincent commented 5 years ago

Config:

resources:
[...]
  - name: version
    type: semver
    source:
      initial_version: 0.0.0-pr.((pr-name)).0
      driver: git
      branch: pipeline-state
      file: ((pr-name)).version
      uri: https://bitbucket/scm/prj/repo.git
[...]
  - name: increment-pr
    serial_groups: [version]
    plan:
    - aggregate:
      - get: source
        trigger: true
      - get: version
        params: {pre: pr.((pr-name))}
    - put: source
      params:
        repository: source
    - put: version
      params: {file: version/number}

When the increment-pr task runs, I get the same output as the input: bumped locally from 1.1.2-pr.project-pr-chad-pipeline-test.1 to 1.1.2-pr.project-pr-chad-pipeline-test.1

Any idea why the patch isn't bumping? Does it not like/allow a period? The value of pre can be anything you like; the value will be pre-pended (hah) to a numeric value.

ccrvincent commented 5 years ago

Follow-up:

I manually bumped the version in pipeline-state and got this:

bumped locally from 1.1.3-pr.project-pr-chad-pipeline-test.2 to 1.1.3-pr.project-pr-chad-pipeline-test.1

But if I switch the period in the pre to a hyphen, it works just fine.

Looks like period is an invalid character in pre, as the pre value will not match properly but will get applied after the "bump".

vito commented 5 years ago

If using a hyphen is acceptable, should we just update the README?

ccrvincent commented 5 years ago

Using the hyphen requires some sed work on both sides, as most of our other tools took the semver spec on pre-release notation rather literally, and are expecting the period.

vito commented 5 years ago

Got it. Well, the bug probably lies in pre_bump.go - we don't have a whole lot of bandwidth to work on each of the resources, but I'd be happy to review a PR. The handling of v.Pre seems a bit sketch - it looks like it has 0 and 1 indices hardcoded, whereas it should probably be handling an arbitrary length and only expecting the last 'pre' part to be numeric.