Add a option to include files when tag

[filenwind]

Some times I have files that only want keep in Tag.

Like dist folder, I don't want track in any branch, so I add /dist to .gitignore

But I want dist keep in Tags to release.

By assets document described, add dist to assets is no help.

If a file has a match in .gitignore it will always be excluded.

So, can add a option to include files only when doing tag?

Or have some way to achieve?

Thank you!

[pvdlg]

What "keep in Tag" means? What git command would you run to achieve what you are asking?

[filenwind]

Sorry I didn't describe it very clearly.

In manual, below steps can achieve what I want:

1. Checkout to a new branch XXX
2. build files to ./dist folder
3. force add ./dist folder and commit (because ./dist is in .gitignore) 
4. create a tag so this tag can include ./dist files
5. switch branch back to where you come from
6. delete branch XXX

So in simply, I want ignore some files, but can include in Tag.

At first I thought option assets can do what I want, until I saw the document.

Can this done by semantic-release/git automatically?

Or it doesn't make sense...

Thanks for you help!

[pvdlg]

We can't include files in a Tag, as a tag is only a reference to a commit. The files would be added to the commit (which in turn is referenced by the tag).

Currently we use the command git add --ignore-errors to add the file to be committed.

I guess we can use git add --ignore-errors --force instead, so all files referenced in the assets option would be added to the commit, no matter if they are in .gitignore or not.
I don't think we need an option for that, we can adopt this behavior by default and mention in the doc that everything in assets will be included no matter what's in .gitignore, as it's reasonable to assume that a user adding files in assets actually want them committed.

Would that work for you?

[filenwind]

Not 100% but almost there.

I think make --force be optional will be great, can keep original behavior and create a new one.

Maybe... forceAssets: boolean (default false)?

Sorry I think again, you are right, user adding files in assets actually want them committed.

Thanks!

[pvdlg]

I'm not convinced about adding yet another option.

In which case one would set that option to false?
Doing so would only allow cases where you have dist in your .gitignore and in assets but don't want to include it. If you don't want to include some files then don't add them to assets.

[filenwind]

Yes, sorry I just lost my brain 😆

[semantic-release-bot]

🎉 This issue has been resolved in version 6.0.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[MatthewMi11er]

Just saw this, and I think your assumption here is faulty. As an example, here is the relevant line of my config:

      {
        "path": "@semantic-release/git",
        "assets": ["**"]
      }

I want to include in the commit everything that's changed EXCEPT for what's in the .gitignore. For me the new behavior is unwelcome as I now either need to duplicate my .gitignore in the semantic-release config or I need to be overly explicit about what I want to add.

Not sure the best way to resolve this. NPM does it by having an .npmignore which overrides .gitignore if and only if .npmignore is present.

[pvdlg]

I understand your point, however I don't think we want to encourage the practice of configuring assets with something too loose, for several reasons:

• Files that match are going to be published, so if by mistake your build generate a temporary file at the root of the project and contains sensitive data they would be exposed, without you noticing
• The commit done by the plugin is named as a release commit and is meant to contain a release, not code changes, so with a loose assets you might end up committing code changes by mistake

You should configure your project and build steps to clearly separate what is a build output from the source code. The case of npm is different though because the deliverable can be and often are the same thing. In the case of this plugin, the source code is never considered being part of the release as it is already checked in the repo.
The point of this plugin is to push to the repo only the output of the build, because everything else is already in the repo.

[MatthewMi11er]

Your point is well taken, but part of my build step is to run code cleanup, eg. eslint. If the clean up fails then the build should fail, but if it is able to autofix any issues then there's no reason not to pass the build. If it passes the build and fixed code formatting issues, it should commit those changes along with the updates to the change log.

[MatthewMi11er]

Also, I think the fact that assets supports globs in the first place contradicts the desire for specificity. As you mentioned the desire is to not mistakenly include things you don't want in the commit. The normal way to do that is .gitignore, so now this change breaks that assumption and along with the globs makes it MORE likely that something incorrect gets committed.