Problem/Motivation
Currently, our git sensor checks for dirty working tree. That's a good start.
However, if production is switched to a non-conform branch (or not a branch at all), the code is still broken.
With a release managed workflow, even a specific tag should be fixed and everything that is different to it (diff, untracked files) is just wrong.
Proposed resolution
Change the gitDirtyWorkingTree sensor to a generic git sensor.
Execute multiple commands to check for untracked or modified files, and additionally to check if there is any diff to a configured branch / tag.
Remaining tasks
-
User interface changes
New setting "Reference", that is either a hash, branch or tag
The setting could offer a list of available branches or tags to pick in admin settings.
API changes
class rename: SensorGitDirtyTree => SensorGit
New setting "reference"
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 2161767-git_sensor-7.patch | 27.36 KB | blueminds |
| #17 | 2161767-git_sensor-7.interdiff.txt | 6.18 KB | blueminds |
| #9 | 2161767-git_sensor-3.patch | 28.61 KB | blueminds |
| #7 | Screen Shot 2014-01-31 at 14.16.56.png | 57.09 KB | blueminds |
| #7 | Screen Shot 2014-01-31 at 14.16.25.png | 75.78 KB | blueminds |
Comments
Comment #1
miro_dietikerComment #2
miro_dietikerComment #3
blueminds commentedProvided textarea where whatever shell command can be provided to check.
Comment #4
miro_dietikerThank you!
From the description above and discussions we did, we learned that one command execution is not always enough. (especially if we would want to check if submodules are initialized properly and more...)
Now you're passing the problem to find the right command to the user. That was not the intention...
I would have expected an optional dropdown to pick a branch or a tag.
Let's see what Berdir wants for the initial release. We should remain simple.
Comment #5
miro_dietikerComment #6
berdirHm. It's also a security problem. This basically opens up the possibility to do any kind of script execution through the UI, fun :)
Comment #7
blueminds commentedOkay, did something fancier. What will be a real challenge is test coverage :)
First what it does:
- You need to specify the repository path, which is validate, then it loads branches and tags
- You may select either expected branch or tag - currently both at once is possible which does not make sense, I guess simple JS action that will preselect empty value of the other would be just fine
- It checks for expected tag/branch and then it runs git status --porcelain
See the screenshots - first three are configuration, the last is the sensor detail.
For the tests I suggest to provide a test class that will override the "check" methods and will fail/pass as requested by tests by setting a variable or so. What do you think?
Comment #9
blueminds commentedHere are tests as well + some minor fixes.
3 Tests will fail - will fix them. But the code is ready for review
Comment #12
blueminds commentedLets try, merged manually number of conflicts...
Comment #14
blueminds commentedyup... unexpected refactoring ;)
Comment #15
blueminds commentedSomehow the old sensor git dirty tree got in.
Comment #16
miro_dietikerA bit feedback here.
The * should be the first posision. Not an unspecified one.
This is bad design. With a check function, you expect that the check might not be successful. It should be true or false and could have an argument by ref.
Exceptions are for unexpected function / API behavior.
Agree, this "*" is the output of the shell command. But it's totally strange to have an API like that and callers need to parse it... We should return something better. Unsure: Is using local variables an option?
Before it was optional. I was talking about possibly removing it from UI. Now you make it even mandatory? Now it's clearly wrong.
Way too complex. You store it as local variable but never use it. And pathes are passed around and checked with git status like crazy.
We cannot be sure git is just there. This needs a check first.
The sensor needs to deal with missing git application in general and show an error message - for instance in the settings form.
Comment #17
blueminds commented1 - 3 fixed
4. it is either the drupal root, or a subdir within the drupal root. In the latter case you need to specify the path. So if drupal root = git root you do not need to do anything
5. do not understand the problem there. The repository path is checked and if found it is stored in local variable. As there are cases when we need to use other than setting value it accepts the argument path.
6. there is no git in tests - we simulate the console output. See exec() method where we switch the test console.
... and yes, i do not like the d.o tracker UX, if anything, i would like to see the previous comments ;)
Comment #18
miro_dietikerSome moore feedback. :-)
That's not a reliable check. Use exec and check the third $return_val argument. It should be 0 in case of success. Otherwise, it's an error and i guess throwing an exception would make sense here.
Bad replace. :-)
Comment #19
miro_dietikerWe're in beta and the sensor is not ready yet.
Thus i committed the escape fix in #2176897: Escape shell commands
Make sure to rebase / reroll the patch.