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

Could provide sample configs for other languages #84

Open
lurch opened this issue May 20, 2017 · 8 comments
Open

Could provide sample configs for other languages #84

lurch opened this issue May 20, 2017 · 8 comments

Comments

@lurch
Copy link
Contributor

lurch commented May 20, 2017

This repo currently provides a versionist.conf.js tailored for NodeJS (npm) projects, which is the tech-stack used by many resin.io projects.
However there are also some resin.io projects using other languages, like go, rust or python (etc.). To help with versionist-standardisation across all resin.io projects, it might be useful if this repo also provided sample config files for the other tech-stacks we use.

Suggested in: balena-io-experimental/edge-node-manager#175 (which possibly provides an example of where this would have been useful).

Tech stack Manifest file Versionist support
NodeJS package.json / npm-shrinkwrap.json / package-lock.json ✓ (but see #103 )
Python setup.py / __init__.py ✓ ( #100 )
Rust Cargo.toml / Cargo.lock ✓ ( #85 , #97 and #104 )
Go ??
Ruby ??
Keyframes keyframe.yml
@lurch
Copy link
Contributor Author

lurch commented Jun 13, 2017

And I've also just noticed that there are projects like https://github.com/resin-io/leech where it's just a bunch of shell scripts, so there's no "package manifest" file to update.

@lurch
Copy link
Contributor Author

lurch commented Jul 13, 2017

Thinking a bit more about this, and prompted by balena-io-modules/open-balena-base#33 and balena-io-modules/device-diagnostics#9 (review) and balena-io-experimental/edge-node-manager#119 (review) ...

Originally, every usage of versionist required there to be an accompanying versionist.conf.js file in the repo, telling versionist how to operate. But then people realised that this meant that all the different resin.io repos that used versionist, would gradually end up over time with slightly different versions of versionist.conf.js, and keeping them all in sync would become impossible. So the decision was made that a "resin.io standard" default versionist.conf.js should be included within versionist itself, so that each repo no longer needed its own config file, and thus they'd all be kept in sync automatically as the version of versionist got updated. This all works fine for repos using NPM, as the default versionist.conf.js inside versionist includes updateVersion: 'npm', as this is the tech-stack used by most of the resin.io repos.

However now that versionist and VersionBot are being deployed more widely over more and more resin.io repos, there are some repos where updateVersion: 'npm' isn't appropriate, and so these repos have to go back to having a full local copy of versionist.conf.js (so far I'm aware of leech, edge-node-manager and resin-base, but I'm sure there are probably others). This means we're back to the situation we were trying to avoid, where we'll end up with different versionist.conf.js files in different repos, gradually drifting more and more out of sync.
AFAICT, in order to fit in with the "resin.io standard" way of working, most of the time the majority of the fields in versionist.conf.js in these non-NPM repos will be identical to the built-in config, with the only exceptions probably being editVersion: or updateVersion:. So I wonder if there could be some kind of "overlay config file" that these non-NPM repos could use, containing just the editVersion: or updateVersion: fields, and then versionist would use all the "resin.io standard" fields from its built-in versionist.conf.js, only 'overriding' those fields specified in this "overlay config file" ?

Ping @hedss @lekkas @brownjohnf @josephroberts @CameronDiver @imrehg

@brownjohnf
Copy link

There is now support for presets in versionist itself, which is probably the right way to go. What I'd like to see is a way to override only certain behavior/functions from the versionist config file without having to include the entire exports object.

@lurch
Copy link
Contributor Author

lurch commented Jul 13, 2017

LOL, snap! ;)

@lurch
Copy link
Contributor Author

lurch commented Jan 19, 2018

See also #100

@lurch
Copy link
Contributor Author

lurch commented Jan 31, 2018

#82 (comment) also provides another example of where versionist needs to be able to bump a version in a file-type not covered above.

Given the awesome work @majorz did in #104 I wonder if a lot of the above file-types not already handled by versionist would be covered by e.g. a quotedPatternReplace preset, which had targetFile and targetPattern parameters (both of which would be mandatory). This means the meta-resin version-bumping needed by @agherzan could be handled by e.g.

updateVersion: {
    preset: 'quotedPatternReplace',
    targetFile: 'meta-resin-common/conf/distro/include/resin-os.inc',
    targetPattern: 'DISTRO_VERSION = '
}

in versionist.conf.js, and then the replace function that @majorz added would be called like:

replace(
    'meta-resin-common/conf/distro/include/resin-os.inc',
    /(DISTRO_VERSION = )("|').*?\2/,
    '$1$2' + cleanedVersion + '$2',
    done
);

and this would then change e.g. DISTRO_VERSION = "2.9.7" to DISTRO_VERSION = "2.9.8" in meta-resin-common/conf/distro/include/resin-os.inc, which would allow meta-resin to start using versionist. (Ah! At least without having to use exec... https://github.com/resin-os/meta-resin/blob/master/versionist.conf.js#L34 ).

If this works, it also means that the Python support @nghiant2710 added in #100 would be functionally equivalent to:

updateVersion: {
    preset: 'quotedPatternReplace',
    targetFile: '__init__.py',
    targetPattern: '__version__\s*=\s*'
}

😉 (of course I'm not suggesting that the initPy preset should be removed, just showing the flexibility that a quotedPatternReplace preset might have)

Maybe the quotedPatternReplace preset would also need an optional targetPatternFlags parameter, to allow e.g. the /g and/or the /m regex modifiers to be specified?

cc @hedss

@hedss
Copy link
Contributor

hedss commented Feb 1, 2018

@lurch I think that's actually a really good idea (and yes, I think the ability to specify flags should also be included).

@lurch
Copy link
Contributor Author

lurch commented Feb 1, 2018

@hedss Cool, just created #110

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

3 participants