Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Log `git checkout` and expose to users #3520
I've been taking a look at the code and I found some consideration that we need to take a look:
Depending on how much we want to refactor, a minimalistic solution would involve:
This is the what this PR implements but, this leaves a mix of calls to
The problem of using always the
It's a good starting point to discuss a little about this.
I think we should be able to set a per-command option to choose whether to record that call ever. It seems like we haven't needed that in the past, but for the VCS stuff we'll want to have a subset of things that aren't recorded.
One question, is there a reason we really don't want all the VCS commands recorded? It might be extra info, but it doesn't seem inherently bad to show them.
I think we should remove the
BaseCLI:run() command from the VCS tools, and move to always just proxying those commands to the
Environment:run(). We really shouldn't have two different ways of running commands in our build process, and the environments are a better abstraction.
The output is a huge improvement, I'm really excited to have this output included and unified with the rest of the command output finally!
I'll echo the sentiment to continue cleaning up the vcs backend code and completely remove the secondary
run() method. I'll also echo the uncertainty of displaying all the commands, could you post some screenshots of the commands all executed through the build environment?
One more thought:
We probably won't want to support this. In the case of our commercial hosting, this step is specifically kept out of the Docker build environment so that the build environment has no read access to the source deploy keys.
I'm working on running all the commands inside a
I just updated this PR with several changes implementing the idea that I commented you both. This is not a final solution but some code to discuss over something concrete.
Summarizing, the idea is to have a
This code will probably needs some polishing and arrangement between us, but it shows the idea I think.
@agjohnson screenshot for all the VCS commands recorded
Now that I've seen how many commands are raised to the user, I feel like there is perhaps some filtering of commands that we need to do. I think it's important to reduce redundancy in the implementations and use a central execution pattern, but it probably isn't useful for users to see all of these commands.
For instance, if we do a
This will probably also get around the issue that a command like
referenced this pull request
Jan 23, 2018
This looks great! I could use some more explanation around moving the update docs task into the main build task, as it seems like a conditional use of the main task. Maybe all that is required here is an abstraction though.
We already discussed the addition of a
run(), but i agree the verbose cli options is a necessary addition for all of the vcs commands. It makes the user view more obvious and makes it easier for development as well.
This was referenced
Jan 23, 2018
In case we want to apply the same method that I used at #3560 (applying the styling in another PR to simplify the review), I wrote this command to do that in an easier way:
Looks great! I'm going to give this some QA before merge, but I just raised a couple of questions on some of the notes we left in code. We can probably update this to make sure our future selves know exactly what needs to change.