tcr,murex

[Feature]: Possibility to personalize git commit message on TCR commits

Is your feature request related to a problem? Please describe.
Current implementation systematically creates new commits with the "TCR" commit message. It would be nice for the user
to customize these commit messages.

Describe the solution you'd like
Use a configuration value with the chosen message (always the same message, maybe with some special fields such as date, time, user)

Describe alternatives you've considered
It would be even better to have more meaningful messages on the "why" of the commit. But this requires for TCR to have an understanding on what happens on every commit, which is not trivial.

Additional context
N/A

[Feature]: Print TCR git commit history

Contact Details

[email protected]

Feature Request

Add the possibility to retrieve easily the git commit history.

Feature Description

Add a subcommand tcr log that allows to print TCR commit history similarly to what git log does.

This tcr log will print out only TCR commits
Repository and branch will be retrieved from TCR base directory, or current directory if base directory is not specified
The subcommand will return an error if base directory does not belong to a git repository

Alternatives

Run git log by hand and filter out the results

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: TCR crashes when language provided as parameter does not exist

Contact Details

[email protected]

Describe the bug

When running TCR with a language parameter value that does not match any of the built-in languages not any of the custom languages defined through configuration files, TCR crashes with the following trace:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x1 addr=0xa0 pc=0x7aaa41]

goroutine 1 [running]:
github.com/murex/tcr/tcr-engine/language.(*Language).setBaseDir(...)
.../tcr/tcr-engine/language/language.go:316

To Reproduce

Steps to reproduce the behavior:

Open a terminal and run tcr -l xxx
The trace shows a runtime error, as described in previous section

Expected behavior

I expected TCR to exit with a message saying that language "xxx" is not supported

Working Environment

OS: Any
Version: TCR v0.10.0

Additional Context

Cause of the error:

call to language.(*Language).setBaseDir(...) on a nil language instance pointer

Fix:

call setBaseDir(...) only when language instance pointer is not nil

Code of Conduct

I agree to follow this project's Code of Conduct

Add support for Go language

Is your feature request related to a problem? Please describe.
This would be nice so that we can apply TCR to itself (eat your own dog food).

Describe the solution you'd like
Either built-in solution, or through a configuration file.

Describe alternatives you've considered
N/A

Additional context
N/A

[Feature]: Turn off GPG passphrase request on git commits

Is your feature request related to a problem? Please describe.
Some users have set up their git configuration so that it asks for GPG passphrase on every commit.

This makes TCR unusable as it's not set up to take input for passphrase every time it runs a commit. Besides, even if it did, that would make a bad user experience due to the potentially high number of commits triggered by TCR.

Describe the solution you'd like
Make sure TCR bypasses the GPG passphrase request when it runs a git commit: git -c commit.gpgsign=false commit

Describe alternatives you've considered
Another solution is to add in the TCR guidelines a remainder to turn off GPG passphrase request on every git commit: git config commit.gpgsign false

This alternate solution is less preferable as it's not transparent from user point of view and forces them to change their git settings for running TCR. Besides signing every TCR commit seems to be an overkill option

Additional context
N/A

[Feature]: Make revert messages more meaningful (to emphasize that tests are not reverted)

Is your feature request related to a problem? Please describe.
In current implementation, the trace messages on test failure always indicate that we are reverting changes. This is actually
not true when only test files have changes, as TCR is not reverting the tests, but only production code.

Describe the solution you'd like
Have a trace message clearly stating that the tests have failed but that nothing was reverted

Describe alternatives you've considered
N/A

Additional context
N/A

Add a structured way for handling menu shortcuts

To do list

Parking Lot

Refactor printMenuOption() so that it directly takes a menuOption instance as a parameter
Extract readKeyboardInput() function that can be used by any menu

[Feature]: Log TCR events

Contact Details

[email protected]

Feature Request

This feature is a prerequisite to [#33]. Its purpose it to generate the data that will be used later on to compute TCR metrics.

Feature Description

With this feature, TCR is logging into ${config_dir}/.tcr/event-log.csv the following events:

Build execution result
Test execution result

The information that is logged with each event is the following:

Timestamp (in UTC)
Number of modified source lines since last commit
Number of modified test lines since last commit
Added test cases (not computed yet. Always 0 at the moment)
Build status (0 = unknown, 1 = build passed, 2 = build failed)
Tests status (0 = unknown, 1 = tests passed, 2 = tests failed)

Information is logged in CSV format so that it can easily be imported into an excel spreadsheet for further computation and analysis.

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: tcr solo crashes trying to launch the periodic reminder

Contact Details

[email protected]

Describe the bug

When running tcr in solo mode, TCR crashes trying to launch the periodic reminder.

The problem exists on the following releases:

v0.13.0
v0.14.0

To Reproduce

Steps to reproduce the behavior:

Make sure to use tcr version 0.13.0 or 0.14.0
Run tcr solo
error trace with tcr 0.13.0:

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x8 pc=0x9a1b0e]

goroutine 51 [running]:
github.com/murex/tcr/tcr-engine/timer.(*PeriodicReminder).Start(0x0)
/home/runner/work/TCR/TCR/tcr-engine/timer/periodic_reminder.go:105 +0x2e
github.com/murex/tcr/tcr-engine/engine.(*TcrEngine).RunAsDriver.func1()
/home/runner/work/TCR/TCR/tcr-engine/engine/tcr.go:192 +0xb6
github.com/murex/tcr/tcr-engine/engine.(*TcrEngine).fromBirthTillDeath.func1()
/home/runner/work/TCR/TCR/tcr-engine/engine/tcr.go:260 +0x38
gopkg.in/tomb%2ev2.(*Tomb).run(0xc0001ec0f0, 0x0)
/home/runner/go/pkg/mod/gopkg.in/[email protected]/tomb.go:163 +0x36
created by gopkg.in/tomb%2ev2.(*Tomb).Go
/home/runner/go/pkg/mod/gopkg.in/[email protected]/tomb.go:159 +0xf3

Expected behavior

TCR should not launch any timer when running in solo mode

Working Environment

OS: any
Versions

v0.13.0
v0.14.0

Additional Context

Additional information

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add a structured way for handling menu shortcuts

Contact Details

[email protected]

Feature Request

Refactor TCR menu shortcuts handling in a more structured way.

This issue comes from Parking Lot in [#142]

Note This is a refactoring ticket. TCR behavior should remain unchanged

Feature Description

TODO

Alternatives

Leave the code as it is

Additional Context

Write your answer here.

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Possibility to put TCR driver mode on hold

Contact Details

[email protected]

Feature Request

Add the possibility to put TCR driver mode on hold. This should have a behavior similar to pressing a pause button.

Feature Description

While in driver mode, add a keyboard shortcut allowing to put all TCR driver operations, for instance:

Stop triggering TCR cycle as soon as a watched file is changes
Put the mob timer on pause
TCR should remain on hold forever, until the user presses a keyboard shortcut resuming TCR driver operations. For instance:
Re-enable triggering TCR cycle on watched files
Resume the mob timer from where it was when "hold" shortcut was pressed.

For TCR shortcuts, proposal is to use the following:

H for putting on hold
R for resuming operations

Alternatives

Currently, the only alternative is to exit driver mode through pressing Q, and then re-entering driver mode through pressing D. The main limitation with this alternative is that the timer restarts from 0.

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Run one single TCR cycle and exit

Contact Details

[email protected]

Feature Request

Having the possibility to run one single TCR cycle without waiting for filesystem changes, and exit right away could be quite handy as it could allow among other things:

To tune and check a new language and/or toolchain more easily
To trigger one TCR cycle more easily from an external script, tool or IDE plug-in

Feature Description

Add a new tcr-cli run-mode (in addition to mob and solo).

This new run-mode should:

be fully automated (no user interaction)
not wait for filesystem changes
run one single TCR cycle and exit
return code should reflect the execution result:

RC	Meaning
0	Build and Test Passed and changes were committed with no error
1	Build failed
2	Build passed, one or more test failed, and changes were reverted
3	Error in configuration or parameters
4	Git error
5	Any other error

Alternatives

N/A

Additional Context

In addition, we could add a shortcut to tcr-cli mob and tcr-gui allowing to trigger execution of a single TCR cycle

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Upgrade TCR's Go build version to 1.19

Contact Details

[email protected]

Feature Request

TCR is currently built with Go 1.18, while version 1.19 has been here for several months already, and version 1.20 has been announced.

Feature Description

Upgrade go version in tcr module from 1.18 to 1.19.

We need to carefully test that there is no regression on TCR, especially related to the changes introduced in version 1.19 to PATH lookups (cf. section "PATH lookups" in Go 1.19 release notes).

We should check in particular that:

All existing toolchains still work as before
Call to various commands assumed to be on the shell path (git, stty, etc.) are still working.
All GitHub actions work properly

Alternatives

Stick with Go 1.18.

Additional Context

Write your answer here.

Code of Conduct

I agree to follow this project's Code of Conduct

Mikado

[Feature]: Add make built-in toolchain

Contact Details

[email protected]

Feature Request

running make is by construction language-agnostic, as it depends on what is configured in the Makefiles provided with the project.
Thus having a make built-in toolchain should be quite convenient for adding new languages.

Feature Description

Add make built-in toolchain, with 2 targets:

make build
make test

This toolchain could be compatible with any language

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add a subcommand to tcr allowing to quickly check that all settings are ok

Contact Details

[email protected]

Feature Request

With the number of options for TCR configuration and customization increasing (especially since the introduction of custom languages and toolchains), having a TCR subcommand allowing to quickly check that everything is set up properly could prove quite handy.

The idea would be to go through all settings, configuration values and command line parameters and tell the user if everything looks consistent, without actually running the TCR engine.

Feature Description

Add a subcommand tcr check that would do the following:

check command line parameters
load configuration values
check that provided directories can be accessed
check that build and test commands can be found (but without running them)
check that base directory is inside a git repository
list files recognized as source files
list files recognized as test files

Return code for this command should be 0 if everything is ok, 1 if there are warnings, 2 if there are errors

Alternatives

Current alternative is to run tcr one-shot.

The main drawback with this alternative is that it can potentially perform an actual git commit or revert, while the proposed tcr check subcommand would not do any change to the repository.

Another potential drawback with using tcr one-shot is when the toolchain's build and/or test command take some time to run.

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add possibility to use other git remote than origin

Contact Details

[email protected]

Feature Request

TCR currently uses origin git remote when processing git push/pull operations. Although it works in majority of cases as origin is created automatically when cloning a repository, there can be situations where it fails:

when the user renamed origin to something else
when the user removed origin

Feature Description

Add a new CLI parameter / configuration setting allowing to specify the name of the git remote.

If this setting is not specified, TCR will use origin as the default value

Alternatives

Add a warning in the README to inform the user that they must have git remote origin properly set in order to run TCR
Enforce this by a checkpoint in tcr check

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Remove cmake-local from built-in toolchains

Contact Details

[email protected]

Feature Request

Toolchain "cmake-local" was added in release v0.9.0 as a temporary solution until our C++ katas have their own local cmake toolchain embedded.

Now that this is done, there is no longer the need to keep "cmake-local" as a TCR built-in toolchain.

Feature Description

Remove toolchain cmake-local from the list of TCR built-in toolchains
Also remove it from the list of compatible toolchains for built-in C++ language

Alternatives

Leave it as a TCR built-in toolchain. But as it's very specific to our katas setup, this toolchain would be useless for anyone not having cmake installed locally with very specific paths.

Additional Context

Write your answer here.

Code of Conduct

I agree to follow this project's Code of Conduct

Possibility to add a custom language

Is your feature request related to a problem? Please describe.
Possibility to add a custom language. This would allow any user to tune TCR to their own context

Describe the solution you'd like
Use of configuration files (yaml), 1 per language

Describe alternatives you've considered
Add built-in languages, just as we currently do with java and C++. This is more robust as it comes built-in in the tool. The drawback is that it's not very flexible. Besides, adding a new language in the tool means releasing a new version of TCR.

Additional context
N/A

Possibility to add a new toolchain

Is your feature request related to a problem? Please describe.
Possibility to add a custom toolchain. This would allow any user to tune TCR to their own context

Describe the solution you'd like
Use of configuration files (yaml), 1 per toolchain

Describe alternatives you've considered
Add built-in toolchains, just as we currently do with gradle, maven and cmake. This is more robust as it comes built-in in the tool. The drawback is that it's not very flexible. Besides, adding a new toolchain in the tool means releasing a new version of TCR.

Additional context
N/A

[Bug]: keyboard shortcuts not properly handled in Intellij Idea embedded terminal on Windows

Contact Details

[email protected]

Describe the bug

On some Windows machines, keyboard shortcuts are not properly handled when running TCR from Intellij Idea embedded terminal using Git Bash.

This seems to be related to some Windows environment settings, as we could not reproduce the problem on another machine using the same Intellij version. It's unclear which settings trigger the different behaviors.

On the machine where the problem was observed:

The same problem appears with GoLand embedded terminal using Git Bash
It does not happen in standalone Git Bash terminal
This behavior is actually the same as what we observe in Windows PowerShell

To Reproduce

Steps to reproduce the behavior:

Open a project with Intellij, open a terminal window (Alt-F12)
Run tcr.exe
Type ? -> the ? character is displayed, but nothing else happens (expected behavior is that the ? character is not displayed, while the list of available options is displayed)
Type ENTER -> the list of available options is displayed
Trace:

[TCR] Starting TCR version v0.11.0...
(...)
[TCR] -------------------------------------------------------------------------
[TCR] What shall we do?
[TCR]   D -> Driver role
[TCR]   N -> Navigator role
[TCR]   P -> Turn on/off git auto-push
[TCR]   Q -> Quit
[TCR]   ? -> List available options
?
[TCR] -------------------------------------------------------------------------
[TCR] Available Options:
[TCR]   D -> Driver role
[TCR]   N -> Navigator role
[TCR]   P -> Turn on/off git auto-push
[TCR]   Q -> Quit
[TCR]   ? -> List available options
'TCR] No action is mapped to shortcut '

Expected behavior

Typing a shortcut key from TCR should trigger the corresponding operation without the need to type ENTER key
the shortcut keys should not be echo-ed in the terminal

Working Environment

OS: Windows

Additional Context

After investigation, it appears that this is related to the windows console stdin mode.

Cf. https://docs.microsoft.com/en-us/windows/console/setconsolemode

In order to have the expected behavior, we need to enforce that the 2 following flags are always disabled on stdin:

ENABLE_LINE_INPUT
ENABLE_ECHO_INPUT

Good news is that fixing this allows to run TCR from Windows Power Shell

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add support for Kotlin language

Is your feature request related to a problem? Please describe.
So that Kotlin developers can use TCR

Describe the solution you'd like
Either a built-in solution or through configuration files

Describe alternatives you've considered
N/A

Additional context
N/A

[Feature]: Add TCR stats query

Contact Details

[email protected]

Feature Request

Add the possibility to browse TCR stats based on git commit history

Feature Description

Add a new "stats" subcommand to TCR.

When running tcr stats, TCR will:

Query git history to retrieve TCR commits. The repository and branch from which git history will be retrieved are automatically retrieved from TCR base directory parameter (current directory if no base directory is specified).
Extract stats and print them.

Stats that will be printed:

Time span (between 1st TCR commit to last one)
Timestamp of first commit
Timestamp of last commit
Number of commits
Number of passing commits (and their ratio vs the number of commits)
Number of failing commits (and their ratio vs the number of commits)
Time in green (total time during which there is no failing test)
Time in red (total time during which there are failing tests)
Number of test cases
Average time between commits
Average number of lines changes per commit (on source files, on test files, and on both)

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Make it easy to manually test the latest TCR sources locally

Contact Details

[email protected]

Feature Request

When adding new features to TCR, it's a bit cumbersome to test the new tool manually. We usually resort to running TCR from the exemples, with a custom command line.

Feature Description

Wrap the custom command line in a script.

It would also be nice to be able to easily debug this latest-built tool seamlessly from the IDE.

Alternatives

have a custom test dir that is updated with the latest TCR as this one is built
or have an extra config in the 'examples' dir

Additional Context

No response

Code of Conduct

I agree to follow this project's Code of Conduct

TODO

Create an alternate script to run TCR from the test data
Make it easy to debug from IDE
- Setup an IntelliJ run config to run TCR
- Document how to run the same thing from any IDE debugger
- Learn about alternative ways to debug by attaching to a running go process
Wrap this in a make run target

[Bug]: TCR in solo mode does not restore terminal input properly

Contact Details

[email protected]

Describe the bug

After exiting "tcr solo", the terminal from which TCR was launched does not echo characters entered on the keyboard, giving the impression that the terminal shell is dead.

To Reproduce

Steps to reproduce the behavior:

From a terminal, run tcr solo to launch TCR in solo mode
Type q to exit TCR
Try typing any character on the keyboard
The typed characters do not appear on the terminal

Expected behavior

TCR should not alter the terminal state when exiting normally

Working Environment

OS: Any
Browser: N/A
Version TCR v0.10.0

Additional Context

When facing the problem, the terminal state can be restored through typing stty echo + ENTER (the terminal's shell actually captures what is typed on the keyboard even if it's not echoed on screen)

Code of Conduct

I agree to follow this project's Code of Conduct

Split existing toolchains in 2 distinct ones

Is your feature request related to a problem? Please describe.
Current toolchains defined in TCR are Murex-biased, e.g. they are tuned to run with our kata structure:

gradle actually relies on gradle wrapper
maven actually relies on maven wrapper
cmake actually assumes that there is a downladed cmake version in the project's build-directory

These are constraints for who wants to use TCR in their own context.

The idea would be to split each of these toolchains into the following ones:

gradle-wrapper (that would be the current gradle toolchain). The pre-requisite is that gradlew is setup on the project
gradle (that would call gradle, wherever it's installed). The pre-requisite would then be that the user has gradle on their path
maven-wrapper (that would be the current maven toolchain). The pre-requisite is that mvnw is setup on the project
maven (that would call maven, wherever it's installed). The pre-requisite would then be that the user has maven on their path
cmake-wrapper (this one still needs to be clarified. We probably need to come up with some kind of cmake wrapper script)
cmake (that would call cmake, wherever it's installed). The pre-requisite would then be that the user has cmake on their path

Describe the solution you'd like
Probably better to have them as built-in in TCR

Describe alternatives you've considered
Rely on toolchain configuration files

Additional context
N/A

[Feature]: Add support for C# language

Contact Details

[email protected]

Feature Request

So that C# developers can use TCR out of the box

Feature Description

Either a built-in solution or through configuration files

Alternatives

Every C# user will have to write their own configuration

Additional Context

Cf. https://github.com/Tr00d/Kata-BowlingGame to use as a starting point for setting up TCR C# configuration

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Remind participants with quotes from experts

Contact Details

[email protected]

Feature Request

TCR has a feature (currently disabled) reminding participants when they didn't save any work for some time.

We could leverage on this feature to regularly display quotes from experts in these reminder messages

Feature Description

Build an "expert quotes" provider service and randomly pull a quote from it every time we send a reminder message.

Alternatives

N/A

Additional Context

We need to try it to make sure it can catch users' attention. Previous tests with the reminder (without expert quotes) showed that users were not really paying attention to them, which is why we disabled it.

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Improve TCR development documentation

Contact Details

[email protected]

Feature Request

Make sure that all information required for starting to contribute to TCR development is available.

Feature Description

Add the following information in dev-doc/build.md

Prerequisite: have make installed
IDE configuration, in particular setup of go tag test_helper which is used when running TCR tests.
Set environment variable CGO_ENABLED=0 for users who do not have gcc installed on their machine

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add bazel as built-in toolchain

Contact Details

[email protected]

Feature Request

Add bazel as a built-in toolchain.

Feature Description

Bazel potentially can work with any language on the 3 platforms macOS/Linux/Windows. This makes it a natural candidate for being defined as a built-in toolchain.

We already have working examples with java, C++ and Go languages.
Need to dig a bit deeper on how to make it work with C# language.

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

To Do

Add example for bazel and java
Add example for bazel and C++
Add example for bazel and go
Add example for bazel and python
Add bazel as a built-in toolchain in TCR application
Add possibility to set test-result-dir configuration value to a symbolic link
Update list of built-in toolchains in README.md

Parking Lot

Add example for bazel and kotlin (TCR built-in bazel toolchain is compatible with kotlin. need to find a working bazel build setup for kotlin)
Add example for bazel and C# (TCR built-in bazel toolchain is compatible with C#. need to find a working bazel build setup for C#)
Update dependabot configuration for bazel-related dependency checks. Not available yet in dependabot, cf. dependabot/dependabot-core#2196

[Feature]: Add notification on test failure and success

Is your feature request related to a problem? Please describe.
Show desktop notification on the following events, in addition to terminal traces:

build failures
test failures (-> revert)
test success (-> commit)

Describe the solution you'd like
Re-use desktop notification mechanisms already used for timer notifications

Describe alternatives you've considered
N/A

Additional context
N/A

[Feature]: Have distinct base directory and working directory

Contact Details

[email protected]

Feature Request

Currently, TCR uses the base directory parameter for 2 different purposes:

As the starting point for searching for source and test files, leveraging on the selected language's filtering rules
As the working directory when launching the selected toolchain's build and test commands

In some situations, we need to be able to launch build and test commands from a directory that is different from the base directory used for searching source and test files

Feature Description

Proposal is to use the directory from which tcr command is executed as the working directory:

The base directory parameter will be used as the starting point for searching for source and test files, leveraging on the selected language's filtering rules
The directory from which tcr command is executed will be used as the working directory when launching the selected toolchain's build and test commands

With this approach users who want to have separate working and base directory can do the following:

cd <working-directory-path>
<path-to-tcr-exe>/tcr --base-dir <base-directory-path>

User who want to use the existing behavior can do it as follows:

cd <base-directory-path>
<path-to-tcr-exe>/tcr

Alternatives

We could also add a new parameter --work-dir for even more flexibility

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: TCR built-in build command in java with gradle does not build tests

Contact Details

[email protected]

Describe the bug

When using TCR with Java language and either gradle or gradle-wrapper toolchains, when there is a build error in a test file while all production files can be built, this error is detected during TCR test phase instead of during TCR build phase. This triggers a revert operation, while it should simply abort the TCR cycle due to build failure.

To Reproduce

Steps to reproduce the behavior:

Open a Java project and start TCR with Gradle or Gradle Wrapper toolchain
Make sure the project passes build and test
Introduce a non breaking change in a production file (for example by adding a comment)
Introduce a build-breaking change in a test file
Save the changes to trigger a TCR cycle
You should observe that build passes, but that tests fail
The breaking changes in the test file are not reverted (which is expected), while the non-breaking changes in the production file are reverted (which is unexpected)

Expected behavior

When build-breaking changes are introduced in either production or test files, TCR should abort the TCR cycle after the build phase and not run the tests nor revert anything.

Working Environment

All TCR versions until v0.19.1
All platforms

Additional Context

The issue is a due to a misunderstanding of the gradle build -x test option: this option forces gradle build to skip running the tests, but it actually also skips building them.

We should replace it with gradle build testClasses -x test which enforces building the tests while skipping their execution.

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Indicate somewhere in TCR Readme that TCR does git commits bypassing GPG signing

Contact Details

[email protected]

Feature Request

Now that TCR does git commits bypassing GPG signing, it can work too for people who have set up GPG signing (cf. #15 ).

We should add a warning somewhere to indicate that TCR does unsigned commits

Feature Description

Add a warning in TCR README.md

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Shared TCR mob session

Contact Details

[email protected]

Feature Request

When using TCR in a mob, it would be nice that everyone in the mob could access the same session information (timer, stats, driver execution trace, etc.)

Feature Description

We could use a serverless solution in order to make this work

Alternatives

N/A

Additional Context

We need to dig into different possible solutions.
May require to have a dedicated instance running somewhere for session management.

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: TCR built-in build command in go does not build tests

Contact Details

[email protected]

Describe the bug

When using TCR with Go language and either go-tools or gotestsum toolchains, when there is a build error in a test file while all production files can be built, this error is detected during TCR test phase instead of during TCR build phase. This triggers a revert operation, while it should simply abort the TCR cycle due to build failure.

To Reproduce

Steps to reproduce the behavior:

Open a Go project and start TCR
Make sure the project passes build and test
Introduce a non breaking change in a production file (for example by adding a comment)
Introduce a build-breaking change in a test file
Save the changes to trigger a TCR cycle
You should observe that build passes, but that tests fail
The breaking changes in the test file are not reverted (which is expected), while the non-breaking changes in the production file are reverted (which is unexpected)

Expected behavior

When build-breaking changes are introduced in either production or test files, TCR should abort the TCR cycle after the build phase and not run the tests nor revert anything.

Working Environment

All TCR versions until v0.19.0
All platforms

Additional Context

The issue is a due to a discrepancy between Go tools build/test commands, and TCR build/test phases:

go build builds only production files, ignoring *_test.go files
go test builds test files and runs the tests

Currently, TCR built-in toolchains for go do the following:

During build phase, run go build ./...
During test phase, run go tests ./... (or gotestsum ./...)

In order to fix this discrepancy, TCR's build command in all Go toolchains should be updated to go test -count=0 ./.... This command allows to build both production and test files without running the tests, which is what we expect in TCR build phase.

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Document adding of a new toolchain and/or language

Contact Details

[email protected]

Feature Request

Now that TCR provides the capability to add a new toolchain or a new language, we need to provide some explanations on how to do it

Feature Description

Add a new section in README.md describing how to proceed

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Improve handling of CTRL-C (SIGINT)

Contact Details

[email protected]

Feature Request

Currently, tcr command does not handle CTRL-C (SIGINT), e.g. it lets the underlying OS interrupt it without interfering.

This is sometimes problematic, due to the fact that TCR turns off terminal echo when it's waiting for the user to press a shortcut. The consequence when this happens is that the user has the feeling that the terminal is in a frozen state.

There is a workaround to this problem (typing stty echo + ENTER), but it would be better if TCR could enforce that the terminal echo is back on before SIGINT-triggered termination.

Feature Description

Add a routine on SIGINT detection that calls stty echo before exiting.

Alternatives

Cf. workaround described in Feature Description section.

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Delete the GUI application

Contact Details

No response

Feature Request

We are facing some issues with maintaining the GUI application

It is lagging behind as we are not updating it
It makes the release process more complex and slower
We are not using it at the moment

Feature Description

We want to remove all the code related to the TCR-GUI application from the repository.
To achieve that, we need to do the following:

Remove the tcr-gui folder
Update GitHub actions
Clean the make file
remove .goreleaser-gui.yml file
Update the ReadMe.md by removing all reference to the GUI
Update the file sonar-project.properties
Remove all the "fyne" files from the folder tools/scripts

In addition to that, we want to merge the tcr-cli and tcr-engine modules.

Alternatives

Implement the new features into the GUI
Not merge the tcr-cli and tcr-engine

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

TODO LIST

[Feature]: Move built-in languages and toolchains into an embedded filesystem

Contact Details

[email protected]

Feature Request

Move built-in languages and toolchains into an embedded filesystem in replacement for having them hard-coded in Go.

Note: this change should not have any impact on TCR's existing behavior related to languages and toolchains management and customization.

Feature Description

Currently, configuration for TCR built-in languages and toolchains is configured directly into go code (in packages tcr-engine/language and tcr-engine/toolchain).

The idea would be to move these hard-coded configurations into yaml files that have the same structure and contents as the configurations files generated through tcr config save command.

These files would then be embedded into TCR binaries at build time leveraging on Go's embedded filesystem feature.

Alternatives

Leave the code as it is and continue to use Go files to describe built-in languages and toolchains configuration

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add support for python language

Contact Details

[email protected]

Feature Request

So that Python developers can use TCR

Feature Description

Add Python as a built-in language
Need to clarify which toolchain to use and how to configure it (especially the build stage, Python being an interpreted language)
Add example(s)
Update README

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

To Do

add a python+pytest example in example directory
tune dependabot.yml to check on 3rd-party updates in python example
update README.md (built-in languages and toolchains section)
add pytest as a built-in toolchain
add python as a built-in language

[Feature]: Add statistics on TCR usage

Contact Details

[email protected]

Feature Request

It would be handy that TCR provides some stats on how it was used.

We need to experiment to understand which stats are the more helpful. Here are some examples of stats that we could provide:

Saving frequency: average number of times per min the user saved one or more files to trigger TCR execution
Average size of changes per save: Average number of lines changed at each save
Build failure rate: average number of failed builds / total number of builds
Commit rate: number of commits / total number of TCR cycles executed
Revert rate: number of reverts / total number of TCR cycles executed
Success rate: number of commits / number of reverts
etc.

Feature Description

We first need to be able to log TCR event history. We will likely need to make the logs persistent if we want to provide stats over time. This will be required also in cases where the user exits and restarts TCR.

List of events that we shall log:

Entering TCR application
Leaving TCR application
Starting a TCR cycle
Build failure
Test failure
Test success
Commit
Revert

If we want to provide mob related stats, we shall also log:

Entering driver mode
Leaving driver mode
Entering navigator mode
Leaving navigator mode

We also need to clarify how the user shall access these stats:

through a dedicated TCR subcommand such as tcr stats
through a shortcut from TCR main menu, for example s that would display current stats

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: tcr stats trace sometimes gets truncated

Contact Details

[email protected]

Describe the bug

Sometimes, when running tcr stats, the trace report is incomplete, e.g. last lines of the report are not displayed, although tcr application exits without error nor crashing.

So far this unexpected behavior has only been reproduced when running tcr from Goland/IntelliJ embedded git bash terminal on Windows. The problem does not seem to happen when running tcr from a standalone git bash terminal.

To Reproduce

Steps to reproduce the behavior:

Open a project setup with tcr in Intellij or Goland
Open the embedded terminal with git bash
Make sure to be on a git branch where TCR was used before (so that git history on that branch contains some TCR-related commits)
Run ./tcrw stats
Look at the trace. When the problem happens, several lines are missing (with normal behavior, last printed line should be [TCR] That's All Folks!)
If the problem doesn't happen, repeat steps 5 and 6.

Expected behavior

Expected output when running tcr stats should look like the following:

[TCR] Starting TCR version 0.19.0...
[TCR] -------------------------------------------------------------------------
[TCR] Running in stats mode
[TCR] Base directory is xxx
[TCR] - Branch: xxx
[TCR] - First commit: Thursday 29 Sep 2022 at 13:07:52
[TCR] - Last commit: Thursday 29 Sep 2022 at 15:19:39
[TCR] - Number of commits: 67
[TCR] - Passing commits: 46 (69%)
[TCR] - Failing commits: 21 (31%)
[TCR] - Time span: 2h11m47s
[TCR] - Time in green: 1h38m13s (75%)
[TCR] - Time in red: 33m34s (25%)
[TCR] - Time between commits: 11s (min) / 1m59s (avg) / 16m46s (max)
[TCR] - Changes per commit (src): 0 (min) / 3.1 (avg) / 19 (max)
[TCR] - Changes per commit (test): 0 (min) / 2 (avg) / 16 (max)
[TCR] - Passing tests count: 0 --> 11
[TCR] - Failing tests count: 0 --> 0
[TCR] - Skipped tests count: 0 --> 1
[TCR] - Test execution duration: 0s --> 0s
[TCR] That's All Folks!

Working Environment

OS: Windows 10
Goland / Intellij version 2022.2.3
TCR version 0.19.0

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add .cxx and .hxx as possible extensions for cpp language

Contact Details

[email protected]

Feature Request

Currently, TCR's cpp built-in language is set to recognize the following file extensions as C++ source files:

.c - .h
.cc - .hh
.cpp - .hpp

Some projects actually use .cxx and .hxx as C++ file extensions. In order to make cpp language settings more inclusive, we should add them to the list of recognized file extensions

Feature Description

Extend cpp language pattern filters to include .cxx and .hxx as valid source file extensions

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Add detailed stats reports

Contact Details

[email protected]

Feature Request

Now that TCR is providing summary stats out of git commit history, it would be nice to also be able to browse detailed stats reports

Feature Description

Generate charts out of TCR stats in HTML/JS format and open them in local navigator.

format of each chart still to be clarified, depending on the capabilities provided by the solution used for generating charts
we could also add some recommendations/advice based on stats data

Alternatives

A more advanced (and likely more expensive) solution could be have TCR instance run its own HTTP server to provide more advanced navigation in the stats report, and allow access from remote navigators.

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

[Bug]: When running with commit-on-fail + git auto-push options, fail and revert commits are not pushed

Contact Details

[email protected]

Describe the bug

When running with commit-on-fail + git auto-push options, fail and revert commits are not pushed right away.

The push only happens after a passing-test commit

To Reproduce

Steps to reproduce the behavior:

Run TCR with --auto-push and --commit-failures options
Update source code to have at least one test failing
Save changes. This will trigger a TCR cycle
At the end of the cycle, there are 2 new local commits (1 with failure, 1 reverting changes)

Expected behavior

The 2 commits should be pushed to origin right after the second commit operation

Working Environment

TCR v0.17.0
All OS

Additional Context

Additional information

Code of Conduct

I agree to follow this project's Code of Conduct

[Feature]: Mark slowest tests as Slow and use `go test -short` when running tcr on tcr

Contact Details

[email protected]

Feature Request

TCR can be slow to run on the whole TCR codebase.

Feature Description

Configure TCR to use go test -short when running tests on the whole TCR codebase

Skip slowest tests in short mode.

Alternatives

Run TCR only on one packages at a time. This is problematic if our changes impact other packages.
Use TCR to report slowest tests and add options to configure tests to skip.
Cross git diff and coverage data to run all but only impacted tests.

Additional Context

This action came out of the Retro we did on 2023-01-24

Code of Conduct

I agree to follow this project's Code of Conduct

TODO

[Feature]: Possibility to easily sync repository contents from within TCR

Contact Details

[email protected]

Feature Request

We sometimes need to synchronize repository contents (files other than watched source or test files).

Having shortcuts allowing to do this without leaving TCR could be handy.

Feature Description

Add 'L' shortcut for pulling the entire repository
Add 'S' shortcut for pushing the entire repository

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

Mikado

Parking Lot

Extract menu texts as constants in terminal_ui.go and terminal_ui_test.go
#196

[Feature]: Add an "examples" directory

Contact Details

[email protected]

Feature Request

Now that the number of language / toolchains supported by TCR is increasing, and to make it more straightforward for people to understand how to tune and use it in their context, it would be nice to have an examples directory with one entry for each language/toolchain pair.

Feature Description

Add the following directory structure at the root of the repository:

examples/
- java-maven/
- java-gradle/
- cpp-cmake/
- etc.

Each subfolder should contain a short README.md explaining how to run TCR with this example, along with pre-requisites.

Alternatives

N/A

Additional Context

N/A

Code of Conduct

I agree to follow this project's Code of Conduct

Mikado

[Feature]: Support Perforce as a VCS

Contact Details

[email protected]

Feature Request

Some teams use Perforce instead of Git as their official VCS.
We need to support using Perforce for them to be able to use TCR on their production code.

Feature Description

TCR can do all the VCS operations with Perforce instead of Git.

Alternatives

Use a temporary Git folder
Use Helix4Git
Explore Git-p4

Additional Context

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Mikado

Parking lot

Move command.go to their own standalone package
Add a tcr command line option to specify the p4 clientName
See if there is an easy way for TCR to automatically detect the underlying VCS
- see if we could use the command env P4CLIENT=xxx p4 status (rc = 0 when cwd is in xxx workspace, rc=1 otherwise)
#228
- Update config/param_polling_period.go
- Prepare a script to automatically update tcr/config.yml once tcr version introduces this change

Possible to use TCR on a local git repository with no remote configured

Discussed in #66

^{Originally posted by Tr00d June 27, 2022}
Hi,

First of all, thanks for building the tool, I'm a big fan and I mostly used the Shell one until recently. I picked up the Go version from version 13.0 with C# support.
It's now a tool I use in most workshops and katas 👍

While trying to demo the tool for someone, I realized I was not able to use it on an empty repository. I didn't find anything in the configuration.
Did I miss something, or is it possible at all?

Repro steps:

Create new solution
Execute git init
Run ./tcr.exe -l csharp check

Here's what I have in the logs:
[TCR] ➤ checking git environment
[TCR] ✔ git command path is C:\Program Files\Git\cmd\git.exe
[TCR] ✔ git version is 2.36.0.windows.1
[TCR] ✔ git username is Guillaume Faas
[TCR] ▼ git remote origin is not set

Thanks a lot and keep up the good work!

murex / tcr Goto Github PK

tcr's People

Contributors

Stargazers

Watchers

Forkers

tcr's Issues

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Describe the bug

To Reproduce

Expected behavior

Working Environment

Additional Context

Code of Conduct

To do list

Parking Lot

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Describe the bug

To Reproduce

Expected behavior

Working Environment

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Mikado

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request

Feature Description

Alternatives

Additional Context

Code of Conduct

Contact Details

Feature Request