feat: allow templating of registry and name#56
feat: allow templating of registry and name#56eliotstocker wants to merge 1 commit intoesatterwhite:mainfrom
Conversation
esatterwhite
left a comment
There was a problem hiding this comment.
Just one nit picky thing, otherwise this seems good to me
| registry | ||
| , project: opts.project | ||
| , name: opts.name | ||
| , name | ||
| , dockerfile: opts.dockerfile | ||
| , build_id: opts.build | ||
| , cwd: context.cwd | ||
| , tags: tags | ||
| , tags |
There was a problem hiding this comment.
nit: would you mind keeping the longhand style consistent? name: name
There was a problem hiding this comment.
Would you mind adding something in the tests that illustrates that this works?
There was a problem hiding this comment.
👍 sure thing ill get on it as soon as i have a moment!
|
Out of curiosity, whats the use case? |
|
using it inside of a preset, so passing the image name as an env var makes things much easier 😄 |
Isn't the preset config a JS module? couldn't you just pull in what ever variables need to be in there? module.exports = {
branches: ['main']
plugins: [
['@codedependant/semantic-release-docker', {
dockerTags: ['latest', '{{version}}', '{{major}}-latest', '{{major}}.{{minor}}'],
dockerFile: 'Dockerfile',
dockerImage: process.env.DOCKER_IMAGE_NAME,
dockerRegistry: process.env.DOCKER_REGISTRY,
dockerProject: process.env.DOCKER_PROJECT,
}]
]
}Or 1 variable that you parse out the bits. I'm not saying what you have here is a bad thing. It just starts to create some sprawl as to where variables are resolved. And it may be solvable with what currently exists. You can tell me I am wrong |
I have a use case that requires templating on name and registry, hopefully the code is very self explainitory 😄