Config options not being picked up #12
Labels
bug
Something isn't working
Comments
|
As an addendum, it would be good if |
|
@sashahilton00, sorry I'm just getting around this. templating wouldn't be too hard to add at all. DEBUG=* DEBUG_DEPTH=100 DEBUG_HIDE_DATE=1 semantic-release |
|
Sure, I’m travelling at the moment so probably won’t be able to test it again immediately, but will post when I get a chance. |
|
Additionally, which version of semantic-release are you using? |
If you are in a bind, I'm pretty sure the semantic-release cli lets you pass arbitrary options that get passed along. semantic-release --dockerImage=foobar --dockerProject=${ENV_VAR} |
|
Ok, so using the latest version of semantic release (18.0.0) with the following configuration: ---
branch: master
preset: 'conventionalcommits'
plugins:
- "@semantic-release/commit-analyzer"
- "@semantic-release/release-notes-generator"
- "@semantic-release/changelog"
- "@semantic-release/git"
- "@semantic-release/gitlab"
- "@semantic-release/exec"
- path: "@codedependant/semantic-release-docker"
dockerImage: 'redacted-repo'
dockerRegistry: 'registry.gitlab.com'
dockerProject: 'redacted-org'
dockerTags:
- latest
- '{version}'
# Responsible for verifying conditions necessary to proceed with the release:
# configuration is correct, authentication token are valid, etc...
verifyConditions:
- '@semantic-release/changelog'
# Verify the presence and the validity of the configuration
- '@semantic-release/git'
# Verify the presence and the validity of the Git authentication
# and release configuration
- '@semantic-release/gitlab'
# Verify the presence and the validity of the GitLab authentication
# and release configuration
# GITLAB_TOKEN must be defined in the CI and contain a personal access token with api and write_repository access.
- '@codedependant/semantic-release-docker'
# Responsible for determining the type of the next release (major, minor or patch).
# If multiple plugins with a analyzeCommits step are defined, the release type will be
# the highest one among plugins output.
# Look details at: https://github.com/semantic-release/commit-analyzer#configuration
analyzeCommits:
- path: "@semantic-release/commit-analyzer"
releaseRules:
- breaking: true
release: major
- type: build # Changes that affect the build system or external dependencies
# (example scopes: gulp, broccoli, npm)
release: patch
- type: chore # Other changes that don't modify src or test files
release: false
- type: ci # Changes to our CI configuration files and scripts
release: false
- type: docs # Documentation only changes
release: patch
- type: feat # A new feature
release: minor
- type: fix # A bug fix
release: patch
- type: perf # A code change that improves performance
release: patch
- type: refactor # A code change that neither fixes a bug nor adds a feature
release: false
- type: revert # Reverts a previous commit
release: patch
- type: style # Changes that do not affect the meaning of the code
# (white-space, formatting, missing semi-colons, etc)
release: false
- type: test # Adding missing tests or correcting existing tests
release: false
# Responsible for generating the content of the release note.
# If multiple plugins with a generateNotes step are defined,
# the release notes will be the result of the concatenation of each plugin output.
generateNotes:
- path: "@semantic-release/release-notes-generator"
writerOpts:
groupBy: "type"
commitGroupsSort:
- "feat"
- "fix"
- "perf"
- "docs"
commitsSort: "header"
linkCompare: true
linkReferences: true
presetConfig:
types:
- type: 'build'
section: '🦊 CI/CD'
hidden: true
- type: 'chore'
section: 'Other'
hidden: true
- type: 'ci'
section: '🦊 CI/CD'
hidden: true
- type: 'docs'
section: '📔 Docs'
hidden: false
- type: 'example'
section: '📝 Examples'
hidden: false
- type: 'feat'
section: '🚀 Features'
hidden: false
- type: 'fix'
section: '🛠 Fixes'
hidden: false
- type: 'perf'
section: '⏩ Performance'
- type: 'refactor'
section: ':scissors: Refactor'
hidden: true
- type: 'revert'
section: '🙅️ Reverts'
- type: 'style'
section: '💈 Style'
hidden: true
- type: 'test'
section: '🧪 Tests'
hidden: true
# Responsible for preparing the release, for example creating or updating files
# such as package.json, CHANGELOG.md, documentation or compiled assets
# and pushing a commit.
prepare:
- path: "@semantic-release/changelog"
changelogFile: "CHANGELOG.md"
# Create or update the changelog file in the local project repository
- path: "@semantic-release/git"
message: 'chore(release): release ${nextRelease.version}'
assets:
- "CHANGELOG.md"
# Push a release commit and tag, including configurable files
- path: "@codedependant/semantic-release-docker"
# Build docker image from Dockerfile.
# Responsible for publishing the release.
publish:
- path: '@semantic-release/gitlab'
# Publish a GitLab release
# (https://docs.gitlab.com/ce/user/project/releases/index.html#add-release-notes-to-git-tags)
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases new ${nextRelease.version}'
# Prepare release on sentry.io
# This requires the SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT env variables to be set.
# The first 1/2 are set at a group level. The latter variable(s) is set at a project level.
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases set-commits ${nextRelease.version} --auto'
# Auto detect commits that form the release
- path: "@codedependant/semantic-release-docker"
# Tag and upload docker image to registry.
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases finalize ${nextRelease.version}'
# Finalise release on sentry.ioResults in: However, when moving plugin configuration to the ---
branch: master
preset: 'conventionalcommits'
plugins:
- "@semantic-release/commit-analyzer"
- "@semantic-release/release-notes-generator"
- "@semantic-release/changelog"
- "@semantic-release/git"
- "@semantic-release/gitlab"
- "@semantic-release/exec"
- "@codedependant/semantic-release-docker"
# Responsible for verifying conditions necessary to proceed with the release:
# configuration is correct, authentication token are valid, etc...
verifyConditions:
- '@semantic-release/changelog'
# Verify the presence and the validity of the configuration
- '@semantic-release/git'
# Verify the presence and the validity of the Git authentication
# and release configuration
- '@semantic-release/gitlab'
# Verify the presence and the validity of the GitLab authentication
# and release configuration
# GITLAB_TOKEN must be defined in the CI and contain a personal access token with api and write_repository access.
- '@codedependant/semantic-release-docker'
# Responsible for determining the type of the next release (major, minor or patch).
# If multiple plugins with a analyzeCommits step are defined, the release type will be
# the highest one among plugins output.
# Look details at: https://github.com/semantic-release/commit-analyzer#configuration
analyzeCommits:
- path: "@semantic-release/commit-analyzer"
releaseRules:
- breaking: true
release: major
- type: build # Changes that affect the build system or external dependencies
# (example scopes: gulp, broccoli, npm)
release: patch
- type: chore # Other changes that don't modify src or test files
release: false
- type: ci # Changes to our CI configuration files and scripts
release: false
- type: docs # Documentation only changes
release: patch
- type: feat # A new feature
release: minor
- type: fix # A bug fix
release: patch
- type: perf # A code change that improves performance
release: patch
- type: refactor # A code change that neither fixes a bug nor adds a feature
release: false
- type: revert # Reverts a previous commit
release: patch
- type: style # Changes that do not affect the meaning of the code
# (white-space, formatting, missing semi-colons, etc)
release: false
- type: test # Adding missing tests or correcting existing tests
release: false
# Responsible for generating the content of the release note.
# If multiple plugins with a generateNotes step are defined,
# the release notes will be the result of the concatenation of each plugin output.
generateNotes:
- path: "@semantic-release/release-notes-generator"
writerOpts:
groupBy: "type"
commitGroupsSort:
- "feat"
- "fix"
- "perf"
- "docs"
commitsSort: "header"
linkCompare: true
linkReferences: true
presetConfig:
types:
- type: 'build'
section: '🦊 CI/CD'
hidden: true
- type: 'chore'
section: 'Other'
hidden: true
- type: 'ci'
section: '🦊 CI/CD'
hidden: true
- type: 'docs'
section: '📔 Docs'
hidden: false
- type: 'example'
section: '📝 Examples'
hidden: false
- type: 'feat'
section: '🚀 Features'
hidden: false
- type: 'fix'
section: '🛠 Fixes'
hidden: false
- type: 'perf'
section: '⏩ Performance'
- type: 'refactor'
section: ':scissors: Refactor'
hidden: true
- type: 'revert'
section: '🙅️ Reverts'
- type: 'style'
section: '💈 Style'
hidden: true
- type: 'test'
section: '🧪 Tests'
hidden: true
# Responsible for preparing the release, for example creating or updating files
# such as package.json, CHANGELOG.md, documentation or compiled assets
# and pushing a commit.
prepare:
- path: "@semantic-release/changelog"
changelogFile: "CHANGELOG.md"
# Create or update the changelog file in the local project repository
- path: "@semantic-release/git"
message: 'chore(release): release ${nextRelease.version}'
assets:
- "CHANGELOG.md"
# Push a release commit and tag, including configurable files
- path: "@codedependant/semantic-release-docker"
dockerImage: 'redacted-repo'
dockerRegistry: 'registry.gitlab.com'
dockerProject: 'redacted-org'
dockerTags:
- latest
- '{version}'
# Build docker image from Dockerfile.
# Responsible for publishing the release.
publish:
- path: '@semantic-release/gitlab'
# Publish a GitLab release
# (https://docs.gitlab.com/ce/user/project/releases/index.html#add-release-notes-to-git-tags)
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases new ${nextRelease.version}'
# Prepare release on sentry.io
# This requires the SENTRY_AUTH_TOKEN, SENTRY_ORG and SENTRY_PROJECT env variables to be set.
# The first 1/2 are set at a group level. The latter variable(s) is set at a project level.
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases set-commits ${nextRelease.version} --auto'
# Auto detect commits that form the release
- path: "@codedependant/semantic-release-docker"
# Tag and upload docker image to registry.
- path: "@semantic-release/exec"
cmd: 'sentry-cli releases finalize ${nextRelease.version}'
# Finalise release on sentry.ioThe following is logged: As you can see, the plugin picks up the configuration for the prepare, then still proceeds to throw a |
|
@sashahilton00 Thanks for the detailed report. This gives me a lot to go on. In all honesty, I wasn't aware that you could configure specific steps like this "verifyConditions": [
"@semantic-release/changelog",
"@semantic-release/git",
"@semantic-release/gitlab",
"@codedependant/semantic-release-docker"
]If all of the steps use the same plugins, I generally don't think you need to do that and would probably lead to some of the behaviors you are seeing. I would have just specified the globals and omitted the step specific configs. {
"branch": "master",
"preset": "conventionalcommits",
"dockerTags": [
"latest",
"{version}"
],
"dockerImage": "sample-image",
"dockerRegistry": "registry.gitlab.com",
"dockerProject": "sample-org",
"writerOpts": {
"commitsSort": "header",
"groupBy": "type",
"commitGroupsSort": [
"feat",
"fix",
"perf",
"docs",
],
"releaseRules": [
{"breaking": true, "release": "major"},
...
]
},
"plugins": [
"@semantic-release/commit-analyzer",
["@semantic-release/release-notes-generator", {...}]
"@semantic-release/changelog",
"@semantic-release/git",
["@semantic-release/gitlab", {...}]
"@codedependant/semantic-release-docker",
]
}This is probably a result of the way plugin config is handled via semantic release, and in transparency, not something I really took into account. I would bet the plugin is being re-instantiated at each step and the global config may not be passed from semantic-release. Not sure. I'll look into it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am seeing some issues when using
3.0.0with the following configuration:or alternatively in YAML:
It appears to be failing because it does not pick up the
dockerImagevariable. The stack trace is as follows:I should note that passing the options at the top level (i.e. not at the plugin level) as follows does allow it to run:
The text was updated successfully, but these errors were encountered: