Problem: Added ignoring features need to
be described somewhere to be visible
for users.
Solution: Add such a description to the
`Usage` part of `README.md`
Problem: There are no tests checking ignoring
regex performance.
Solution: Add test checking that broken links
matched by regexs are not verified and
test checking that not matched broken links
are verified as links with error.
Problem: There are no tests checking the performance
of different ignoring modes.
Solution: Add such tests to `Xrefcheck.Test.IgnoringSpec`.
Also add markdowns to test on real files.
Problem: There is no mention of ignoring modes in
help message.
Solution: Add a footer with a description of
each ignoring mode to `getCommand` function
of `Xrefcheck.CLI`.
Problem: It can be convenient not only specifying
exclusions in the config, but also annotating
the excluded thing right in-place. It is about
adding comment before the link or the paragraph
or even the whole file to ignore this item.
Solution: Support annotation as html comment in
a "<!-- xrefcheck: ignore mode -->" format, where
mode is "link" or "paragraph" or "file". Modify
`nodeExtractInfo` from `Xrefcheck.Scanners.Markdown`
just to skip a node in AST while parsing. Take into
account that "ignore file" can only be at the top
of the file or right after the license. In markdown
terms: either the first node must be HTML_BLOCK
with "<!-- xrefcheck: ignore file -->" content
or the first is HTML_BLOCK comment (smth
between "<!--" and "-->") and the second is
HTML_BLOCK with "ignore file" content.
Also take into account that "ignore link" must be
followed by a link. Strictly speaking, there is
either LINK after "ignore link" or TEXT and LINK
(if there is some text before the link).
Problem: External links must be ignored sometimes
and not be checked for validity.
Solution: Add `vcIgnoreRefs` to `Config` that is a list
of regexs using `regex-tdfa`. Each regex define a link
we want to ignore while validating. Change
`checkExternalResource` to support matching the regex.
Problem: there seems to be another popular tool for HTMLs verification
called `linkcheck`, it is stated to be way better than
`broken-link-checker`.
Solution: replace `broken-link-checker` mention with `linkcheck`, say
that there are other solutions to this problem.
Also make the paragraph a bit more clear in general.
Problem: @gromakovsky has recently implemented a github action which
adds xrefcheck pass to CI and it resides in a separate repository, we
want it to be visible in our documentation here.
Solution: mention it in `Usage` section.
Without it skopeo fails because it requires configured policy file to
verify downloaded images, but we don't need a policy file because we
only use skopeo for uploading
Problem: `stack upload` does not like that `base` does not have an
upper bound, it reports an error while checking the package.
Solution: add an upper bound on `base` to prevent people from using a
broken version of this package in case of breaking changes in `base`.
Since we build with stack, our current default is 4.13 (deduced from
the resolver). However, 4.14 does not seem to have any breaking changes
https://hackage.haskell.org/package/base-4.14.0.0/changelog
so it should be fine to permit it as well, and that's what we are doing.
Problem: we have two major use cases:
1. Using xrefcheck in CI, in this case it is annoying for devops to
always pass mostly always reasonable `--no-progress` option.
2. Using it locally, here we want progress bar to be enabled by default
so that user could run `xrefcheck` without any options most of the time.
Solution:
Detect whether are we running in CI and use the respective default for
whether progress bar should be displayed.
Detecting whether we are within CI is possible using `CI` env variable,
at least Github actions, Gitlab CI and Buildkite pass this env.
`--no-progress` option still can be passed if user wants to suppress
progress bar in local run. The opposite `--progress` seems to also make
sense, because in case if high timeouts are set, user probably wants to
track progress somehow to make sure that CI didn't hang. So we add the
latter, and these two options can be used to override the default
behaviour defined by `CI` env var.
Problem: LTS-14.16 that we currently using and a bit old.
And its GHC is old as well.
Solution: update the resolver, make some changes that were necessary.
They are pretty trivial. The only essential breaking change is the
removal of `parseUrl` from `req`.
