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

Why ".gitignore" is ignored ? #345

Open
merlosy opened this issue Apr 7, 2022 · 6 comments · May be fixed by #527
Open

Why ".gitignore" is ignored ? #345

merlosy opened this issue Apr 7, 2022 · 6 comments · May be fixed by #527

Comments

@merlosy
Copy link

merlosy commented Apr 7, 2022

Hi!
I'd like to understand the motivation for adding files that are ignored to the next commit.

For example, my project build outputs code into a dist folder. This should be published as part of the artifact on the registry.
But I don't want to find those dist files in the code (pollution IMO).

It seems like a common use case. Am I the only one troubled by this?

Thanks,

@travi
Copy link
Member

travi commented Apr 7, 2022

#56 has the history of why this was done in this way

@merlosy
Copy link
Author

merlosy commented Apr 12, 2022

Thanks for the link!

It was not very intuitive to explicitly define the assets, but I get it. I'll be able to test it soon on my side

@MrAntix
Copy link

MrAntix commented Aug 11, 2022

:( I don't get it, I looked at the link, and could not see why, just that it was going to be done

I am building a package to go in the github registry

If I don't include the dist folder in the .releaserc assets, they don't go into the package
If I do, then they go into the package AND committed into the repo

As they are committed, they are pulled down by the developer and when they build locally the files become a change.

The assets for the package are built files and should be in the package but not committed - how do I do that?

  • also as a side note there is a loader directory, which I have not added to assets, but is added to the package but not committed

@travi
Copy link
Member

travi commented Aug 11, 2022

I am building a package to go in the github registry

it sounds like your problem is likely unrelated to this issue. you may not even need this git plugin at all. the github registry works the same as other npm registries, so you just need to inform npm which files to include through files in package.json or through a .npmignore (we recommend the files option, specifically because it is an allow-list rather than a deny list).

@MrAntix
Copy link

MrAntix commented Aug 12, 2022

thanks for the reply

I needed to look at the github npm plugin and this one

just for anyone else who ends up here, this gets me what I wanted

.releaserc

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "@semantic-release/changelog",
      {
        "changelogFile": "CHANGELOG.md"
      }
    ],
    "@semantic-release/npm",
    [
      "@semantic-release/git",
      {
        "assets": [
          "CHANGELOG.md", "package.json"
        ],
        "message": "chore(release): set `package.json` to ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }
    ]
  ],
}

@semantic-release/npm

creates and publishes packages - to npm or github depending on your registry settings, assets from the package.json > files setting e.g.

package.json

{
  "files": [
    "dist/",
    "loader/"
  ],
}

@semantic-release/git

commits changes from the build that are in the assets setting in .releaserc (see above)

@semantic-release/github

creates GitHub Releases - not packages

ctreatma added a commit to equinix/equinix-sdk-python that referenced this issue Aug 20, 2024
The `.openapi-generator` directory is already mentioned in `.gitignore`,
but it had not been removed from the repository. In addition to removing
that directory, this updates the Makefiles so that the
`.openapi-generator` directory is explicitly removed whenever code is
regenerated.

We have to explicitly remove this directory because the
`semantic-release/git` plugin [intentionally does not respect
`.gitignore`](semantic-release/git#345), so
these files will be re-committed on every release if they are not
explicitly removed during code generation.
jkallem-equinix pushed a commit to equinix/equinix-sdk-python that referenced this issue Aug 21, 2024
The `.openapi-generator` directory is already mentioned in `.gitignore`,
but it had not been removed from the repository. In addition to removing
that directory, this updates the Makefiles so that the
`.openapi-generator` directory is explicitly removed whenever code is
regenerated.

We have to explicitly remove this directory because the
`semantic-release/git` plugin [intentionally does not respect
`.gitignore`](semantic-release/git#345), so
these files will be re-committed on every release if they are not
explicitly removed during code generation.
jkallem-equinix pushed a commit to equinix/equinix-sdk-python that referenced this issue Aug 21, 2024
The `.openapi-generator` directory is already mentioned in `.gitignore`,
but it had not been removed from the repository. In addition to removing
that directory, this updates the Makefiles so that the
`.openapi-generator` directory is explicitly removed whenever code is
regenerated.

We have to explicitly remove this directory because the
`semantic-release/git` plugin [intentionally does not respect
`.gitignore`](semantic-release/git#345), so
these files will be re-committed on every release if they are not
explicitly removed during code generation.
Kenneth-Sills added a commit to Kenneth-Sills/semantic-release-git-plugin that referenced this issue Nov 8, 2024
Per maintainer desire and to ensure backwards compatibility, this is
disabled by default.

Closes semantic-release#345
Closes semantic-release#347
@Kenneth-Sills
Copy link

This and #347 are really the same and can be deduped. PR #527 is set to address this by adding a simple respectIgnoreFile toggle that allows opting-in to the old behavior.

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

Successfully merging a pull request may close this issue.

4 participants