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.

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

Deploy can be run with uncommitted changes #1276

Closed
bobbygryzynger opened this issue Mar 31, 2017 · 4 comments
Closed

Deploy can be run with uncommitted changes #1276

bobbygryzynger opened this issue Mar 31, 2017 · 4 comments
Assignees
@bobbygryzynger
Labels
Enhancement A feature or feature request

Comments

@bobbygryzynger
Copy link
Contributor

bobbygryzynger commented Mar 31, 2017 •
edited
Loading

In version 8.6.14 I am able to run blt deploy with uncommitted changes and these changes will be included in my deploy. This is a potentially dangerous capability as it could cause a lot of unintentional changes to end up on a remote environment.

Ideally, BLT would check the working tree and enforce that it is clean before allowing a deploy to proceed.
@bobbygryzynger bobbygryzynger changed the title BLT deploy can be run with uncommitted changes Deploy can be run with uncommitted changes Mar 31, 2017
@bobbygryzynger bobbygryzynger mentioned this issue Mar 31, 2017
Merged
@grasmash grasmash added the Enhancement A feature or feature request label Mar 31, 2017
@grasmash grasmash reopened this Apr 4, 2017
@grasmash
Copy link
Contributor

grasmash commented Apr 4, 2017

@bobbygryzynger I had to revert the PR for this. It caused: #1308, as well as an issue with the deploy_tag script.

@bobbygryzynger
Copy link
Contributor Author

bobbygryzynger commented Apr 4, 2017 •
edited
Loading

@grasmash - are there some flag values that could be checked before inspecting the working tree? It seems like #1308 could be overcome by ensuring that ${environment} is not ci or is local. I don't know if something similar could be used to ensure there are no conflicts with the deploy_tag script.

@bobbygryzynger
Copy link
Contributor Author

Another thought: a git.failOnDirty: true property could be added to build.yml which could be checked in deploy and overridden where need be.

@grasmash
Copy link
Contributor

grasmash commented Apr 5, 2017

@bobbygryzynger Yeah I think git.failOnDirty would be fine. We could default it to TRUE and then set it to FALSE during CI.

@bobbygryzynger bobbygryzynger mentioned this issue Apr 10, 2017
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bobbygryzynger bobbygryzynger

Labels
Enhancement A feature or feature request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@grasmash @bobbygryzynger