1365734 - Handle BMO version number in Makefile.PL / MYMETA.json

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Dylan Hardison [:dylan] (he/him)]

Neither the upstream method (BUGZILLA_VERSION in Bugzilla::Constants)
nor the BMO customization (setting a parameter for the version number) are acceptable for BMO in the near future.

1. The version will be defined in Bugzilla.pm, as our $VERSION = 'YYYYMMDD.xx'.
2) This will be extracted by Makefile.PL and written into MYMETA.json
3) version.json will pull this from that file.
4) templates will also pull it from this file.
5) the version will be updated with a commit and that commit tagged for all future deployments.

Comment 1

[Dylan Hardison [:dylan] (he/him)]

Attachment: 1365734_1.patch

Comment 2

[:glob ✱]

(In reply to Dylan Hardison [:dylan] (he/him) from comment #0)
> Neither the upstream method (BUGZILLA_VERSION in Bugzilla::Constants)
> nor the BMO customization (setting a parameter for the version number) are
> acceptable for BMO in the near future.

it seems to me that if you're reworking this code, it would be better to set it automatically when checksetup is run (or similar), so the version is always bound with the deployment date without needing to remember to update Bugzilla.pm.

Comment 3

[Dylan Hardison [:dylan] (he/him)]

I'd rather it work like any other perl package. As we move to a more cloudy deployment, I will start tagging releases as well.

Comment 4

[:glob ✱]

Comment on attachment 8870406 [details] [diff] [review]
1365734_1.patch

Review of attachment 8870406 [details] [diff] [review]:
-----------------------------------------------------------------

r=glob

these changes look good as is, however i'm concerned that it would be too easy to forgot to update the version number before deployment, requiring a second push to address it -- the version being part of index's etag makes this more impactful than just a visible string.

would it be possible/valuable to add a test that warns when the version hasn't been updated?

Comment 5

[Dylan Hardison [:dylan] (he/him)]

(In reply to Byron Jones ‹:glob› from comment #4)
> would it be possible/valuable to add a test that warns when the version
> hasn't been updated?

Possible, yes, but with trade-offs:

1) I could base it on the date (if the version is not a future date, disallow) but that seems fragile
2) I could try connecting to github and seeing if the current branch's version is the same as production, and fail then. This requires network access and seems fragile for other reasons
3) I could locally run git to determine this -- but I'd need to make sure the production branch was pulled down.

The problem all boils down to state.

I don't mean to hand-wave away, but I think it is better to update the process documentation
and live with the risk for now. Some of the constraints we're under now won't exist when deployment happens in a more containerized fashion.

Comment 6

[Dylan Hardison [:dylan] (he/him)]

... we're under now won't exist when deployment happens in a more containerized fashion, and we can revisit how the version is updated. Perhaps using git metadata, like tags. Or have CI ensure that the tag/version must match, etc.

Comment 7

[Dylan Hardison [:dylan] (he/him)]

To [e-mail]:mozilla-bteam/bmo.git
   5d6b042..9701901  master -> master

Comment 8

[Dylan Hardison [:dylan] (he/him)]

Documentation updated: https://mana.mozilla.org/wiki/pages/diffpagesbyversion.action?pageId=52266989&selectedPageVersions=12&selectedPageVersions=11

Comment 9

[:glob ✱]

(In reply to Dylan Hardison [:dylan] (he/him) from comment #5)
> I don't mean to hand-wave away, but I think it is better to update the
> process documentation and live with the risk for now. Some of the
> constraints we're under now won't exist when deployment happens in a
> more containerized fashion.

makes sense; thanks for the response.