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

Limit files staged by Git during a release #187

Closed
ominestre opened this issue Feb 8, 2020 · 5 comments · Fixed by #196
Closed

Limit files staged by Git during a release #187

ominestre opened this issue Feb 8, 2020 · 5 comments · Fixed by #196
Assignees
Labels

Comments

@ominestre
Copy link
Collaborator

Describe the bug
The current build script uses Git StageAll during a release. If someone has a dirty working directory this could add unintended files to a release.

Expected behavior
Explicitly declare which files should be staged during a release.

@ominestre ominestre added the bug label Feb 8, 2020
@ominestre ominestre self-assigned this Feb 8, 2020
@ominestre
Copy link
Collaborator Author

@TheAngryByrd looking at the history it looks like the only thing that needs staged is the generated HTML files. Is there any AssemblyInfo or anything else I should account for?

@rmunn
Copy link
Contributor

rmunn commented Feb 9, 2020

@ominestre There are some generated AssemblyInfo files, which get put in different places depending on whether it's an F# or C# project. IIRC, F# AssemblyInfo.fs files get put into src/ProjectName/ and tests/ProjectName.Tests/, while C# AssemblyInfo.fs get put into src/ProjectName/Properties/ and tests/ProjectName.Tests/Properties. But I'm not 100% sure of that; you can look at the "GenerateAssemblyInfo" target in the build script to double-check my recollection.

@TheAngryByrd
Copy link
Owner

TheAngryByrd commented Feb 10, 2020

@ominestre The HTML files are staged and committed separately during the ReleaseDocs target so no need to worry about the docsDir.

@halcwb
Copy link
Contributor

halcwb commented Feb 21, 2020

Just my 2 cents. I use a different approach when commit files to git, an opt-in approach. So in my .gitignore I start with explicitly excluding everything and then I handpick which files/dirs can be included. So, it looks like this:

# Ignore all files using an opt-inn approach
*

# Add .gitignore and .gitattributes
!.gitignore
!.gitattributes

# Add license
!LICENSE.txt

# Add todo list
!ToDo.txt

# Add md files
!*.md

# Add fsx files
!*.fsx


# ignore release command
release.cmd
publishnuget.cmd

# Add proc file
!Procfile

# Add local tools config
!/.config/
!/.config/*.json

# Add paket bootstrapper
!/.paket/
!/.paket/paket.bootstrapper.exe

# Add dependencies file
!paket.dependencies
!paket.lock
!paket.references
!paket.template

# Add yml files to ci on appveyor and travis
!appveyor.yml
!.travis.yml

# Add solution file
!*.sln

# Add fsharp project files
!*.fsproj

# Etc...

This way I prevent accidentally adding sensitive or unnecessary files. The downside is that it happens that I forget to include files. But then this will immediately show up on the CI builds.

@ominestre
Copy link
Collaborator Author

I like the idea of whitelisting files to avoid a SNAFU. We'd still have a problem if someone had a dirty working directory with a whitelisted file and they ran the release script. The change I'm looking to make is to replace the stageAll with a more explicit glob for just the assembly data.

ominestre pushed a commit that referenced this issue Mar 7, 2020
Git stage all can accidentally include unintended changes into a release commit. This change explicitly instructs Git to only stage the CHANGELOG and the AssemblyInfo.

Resolves #187
@ominestre ominestre mentioned this issue Mar 7, 2020
6 tasks
TheAngryByrd pushed a commit that referenced this issue Mar 8, 2020
Git stage all can accidentally include unintended changes into a release commit. This change explicitly instructs Git to only stage the CHANGELOG and the AssemblyInfo.

Resolves #187
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants