Skip to content

assets option is ambiguous with git plugin assets option #808

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.

Sign up for GitHub

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

Jump to bottom
Open
esatterwhite opened this issue Apr 5, 2024 · 4 comments · May be fixed by #809
Open

assets option is ambiguous with git plugin assets option #808

esatterwhite opened this issue Apr 5, 2024 · 4 comments · May be fixed by #809

Comments

@esatterwhite
Copy link

esatterwhite commented Apr 5, 2024 •
edited
Loading

Both the git plugin and github plugin have a configuration option named assets. When building out a shareable configuration, It is preferable to omit configuration inline with the plugin and define as much as possible in the top level of the release config so they can be overridden when the configuration is extended.

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  assets: ['package.json', '*.md', '!**/node_modules/**'],  // <---- assets
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', null],
    ['@semantic-release/exec', null],
    ['@semantic-release/github', null]
  ]
}

This works rather well except when you use the git and github plugins together - the assets configuration is ambiguous meaning. In the above example, All .md files will be included in both the release commit, and the files attached to the github release. if the value needs to be different between the two plugins, you have to define the plugin configuration inline, which makes it difficult to change

// my-release-config/index.js
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git', {
      assets: ['package.json', '*.md', '!**/node_modules/**'] // <---- assets
    }]
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']              // <---- assets
    }]
  ]
}

This allows them to be different, But now you cannot really over ride these values individually with out modifying them both, or changing them in the actualy config package being exteded. Which mean people have to re-define the entire plugin change and re-create most of the default configuration shipped with the shared config. Which mostly defeats the purpose.

Ideally, these settings should be named differently to disambiguate them - gitCommitAssets and githubReleaseAssets.
Something to this effect. It could initially be alternate value to allow the existing assets value to work if defined like it currently does.
esatterwhite added a commit to esatterwhite/github that referenced this issue Apr 5, 2024
@esatterwhite
feat: Add githubReleaseAssets option
1aed3e4 
Includes the addition of a new option githubReleaseAssets to replace the
old assets option. The assets option is identical to the option found in
the git plugin but is ambiguous when used in shared configuration
packages.

Fixes: semantic-release#808
@esatterwhite esatterwhite linked a pull request Apr 5, 2024 that will close this issue
Open
esatterwhite added a commit to esatterwhite/github that referenced this issue Apr 10, 2024
@esatterwhite
feat: Add githubReleaseAssets option
0370eb5 
Includes the addition of a new option githubReleaseAssets to replace the
old assets option. The assets option is identical to the option found in
the git plugin but is ambiguous when used in shared configuration
packages.

Fixes: semantic-release#808
esatterwhite added a commit to esatterwhite/github that referenced this issue Apr 17, 2024
@esatterwhite
feat: Add githubReleaseAssets option
8a17388 
Includes the addition of a new option githubReleaseAssets to replace the
old assets option. The assets option is identical to the option found in
the git plugin but is ambiguous when used in shared configuration
packages.

Fixes: semantic-release#808
@babblebey
Copy link
Member

babblebey commented Aug 13, 2024 •
edited by hearts bot
Loading

But now you cannot really over ride these values individually with out modifying them both, or changing them in the actualy config package being exteded. Which mean people have to re-define the entire plugin change and re-create most of the default configuration shipped with the shared config.

I can easily assume that this is how the configurations functions. I'd suggest we make this possible instead of a rename.

I'm interested in understanding the initial thought process behind having the property named assets (i.e. keeping'em uniform) across the plugins and the package itself too 🤔

@esatterwhite
Copy link
Author

esatterwhite commented Aug 13, 2024 •
edited by hearts bot
Loading

I can easily assume that this is how the configurations functions. I'd suggest we make this possible instead of a rename.

It isn't possible to have a single configuration option represent multiple settings.

module.exports = {
  assets: ['package.json', '*.md', '!**/node_modules/**'],
, plugins: [...]
}

There is no way for me to define what gets added to a git commit independently from what is added to a github release without either losing extensibility, or introducing a good amount of complexity.

@gr2m
Copy link
Member

gr2m commented Aug 14, 2024 •
edited by hearts bot
Loading

I don't agree, or maybe don't yet understand why this is better

module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  gitAssets: ['package.json', '*.md', '!**/node_modules/**'],
  githubAssets: ['dist/*.tgz', 'coverage/*.json'],
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git']
    ['@semantic-release/exec', null],
    ['@semantic-release/github']
  ]
}

Than this

module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  assets: ['package.json', '*.md', '!**/node_modules/**']
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git']
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']              // <---- override
    }]
  ]
}

I think being able to define a global default and then override it on a plugin level is a feature, not a bug

@esatterwhite
Copy link
Author

esatterwhite commented Aug 14, 2024 •
edited by hearts bot
Loading

When you extend this as a shareable config, config that is defined at inline with the plugin rather than set globally, it requires the end user to redefine the entire plugin stack so the configuration still works correctly. Which isn't really feasible without being intimately familiar with all of the plugin settings and the setup of the config.
So rather than just being able to extend and set 1 or 2 things

//  release-config-base62
module.exports = {
  npmPublish: false,
  releaseRules: [...],
  changelogTitle: '## Changelog',
  assets: ['package.json', '*.md', '!**/node_modules/**']
  plugins: [
    ['@semantic-release/commit-analyzer', null],
    ['@semantic-release/release-notes-generator', null],
    ['@semantic-release/changelog', null]
    ['@semantic-release/npm', null],
    ['@semantic-release/git']
    ['@semantic-release/exec', null],
    ['@semantic-release/github', {
       assets: ['dist/*.tgz', 'coverage/*.json']   // <---- we have to do this here because github assest rarely match git assets
    }]
  ]
}

Attempting to do this doesn't do what one would expect

{
  // package.json
 "release": {
    "extends": "base62"
  ,  "assets": ["*.md", "package.json", "*.rocskec"]   
  }
}

Not only does this not change the github config, it changes the git config
everyone extending this config has to re-create the plugin chain in the right order and any nested configurations

{
  // package.json
 "release": {
    "extends": "base62"
  , "plugins": [
      ['@semantic-release/commit-analyzer', null],
      ['@semantic-release/release-notes-generator', null],
      ['@semantic-release/changelog', null]
      ['@semantic-release/npm', null],
      ['@semantic-release/git']
      ['@semantic-release/exec', null],
      ['@semantic-release/github', {
        "assets": ["*.md", "package.json", "*.rocskec"]             // <---- override
      }]
    ]
  }
}

If the base config introduces a new plugin or other such things, its a breaking change every time because everyone else now has to update the plugin list. Its confusing, brittle and not very extensible.

I should be able to just set the 1 or 2 things and plainly understand which thing I'm changing.

{
  // package.json
 "release": {
    "extends": "base62"
  ,  "gitAssets": ["*.md", "package.json", "*.rocskec", "**/*.lua"]   
  , "releaseAssets":  ["dist/*.tgz", "coverage/*.json", "build/*"]
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: Add githubReleaseAssets option esatterwhite/github
3 participants
@gr2m @esatterwhite @babblebey