Regardless of the OS on which the app is running,
respect the original line endings of the file
when writing back the issue URL. In the case of
a mixed line-ending file (e.g. both Windows-style
CRLF and Unix-style LF), the issue URL comment
line will use the line ending style of the TODO
comment line above it.
Partially addresses GitHub issue #245
Fix a regression that was accidentally introduced
with v5.1.2 which could cause an issue URL to not
be successfully added to the source file when
dealing with a CRLF (Windows-style line endings)
file on Linux.
Partially addresses GitHub issue #245
Provides a test for and the solution to GitHub
issue #242. Namely, an identifier which contains
regex characters (e.g. "[TODO]") is properly
handled by having the parser look for literal
"[" and "]" characters rather than treating those
characters as part of a regex pattern. The word
boundary regex pattern '\b' does NOT properly
handle this, so a slightly different pattern is
used to identify the boundary.
If TODO comment is a suffix to a line of
(executable) source, don't repeat the source
content when inserting the issue URL. But be sure
to still keep the same alignment.
Closes#229
Added tests for issues #224/#225 and #229. Since
these are known bugs, the tests are currently
marked as expected failures. Once the solution
is implemented, that designation can be removed
and we'll still keep the test to make sure there
aren't any regressions.
If regex characters are part of the title (for
example, parentheses), then this breaks the ability
to find the comment line when trying to insert
the issue URL. This commit escapes the title
to fix this problem.
Closes github.com/alstr/todo-to-issue-action#226
When searching for the comment line after which
the issue URL will be inserted, use a case-insensitive
search for the identifier portion of the line.
This matches how TodoParser identifies TODOs using
a case-insensitive search.
Closes github.com/alstr/todo-to-issue-action#224
There are issues currently where the wrong text
may be inserted in place of the issue URL. (See
github.com/alstr/todo-to-issue-action issues #224
, #225, and #226, for example.) When such a
situation is detected, the offending line is now
NOT inserted and instead a warning message is
printed out. This doesn't completely resolve
those issues, but mitigates against them and
other similar issues which may arise in the future.
Insertion of the URL is different from simply
creating/updating the issue, so we want to have
this level of output to ensure that as many
file updates as expected are actually occurring.
Note: The unit test is currently failing!
Fix bug where if there were multiple issue URLs
to insert into a file, after the first insertion
all further insertions would copy a "random"
line (based on *original* line numbering) and
insert that copy rather than the issue URL.
Now processes files in order by file name
and then in reverse order by line number,
thereby ensuring that any line insertions/
deletions at bottom of file don't affect
line numbering above them.
Closes github.com/alstr/todo-to-issue-action#225
There's no reason to have main directly construct
the URL. A different VCS (such as GitLab) could
have a different URL construction. Further, in the
case of LocalClient, there is no URL.
Add a new method, get_issue_url(), which returns
the VCS-specific web URL for viewing an issue.
This results in moving GitHub-specific code from
main into GitHubClient, but with no change in behavior.
This is just a safe fallback for local testing.
If environment variables which activate the
creation of the GitHub client aren't set, then
the Local client is created. It acts on the most
recent commit of the repo in the working directory.
Minor edit to GitHubClient so that it raises an
EnvironmentError exception if INPUT_GITHUB_URL
environment variable is not defined. This allows
main to detect the error and fall back to trying
to use the Local client
Split main.py into modules to (mostly) isolate the
GitHub-specific code from the general TODO
detection and program logic.
This is both for readability/maintainability and
to prepare for potentially supporting other
version control systems (e.g. GitLab, BitBucket).
