The '! cargo tree -i openssl-sys' command ignores when 'cargo tree'
fails for other reasons than not depending on the openssl-sys crate.
This commit changes the command to propagate such a failure.
* Fix rustls-tls feature
Commit 14e74879 (cookie support #1146) re-introduced an unconditional
dependency on the openssl-sys crate. That is, building Lychee with the
Rustls TLS backend now requires OpenSSL. I suppose this change was
unintended, maybe due to automatic conflict resolution. If not, please
let me know.
You can review the re-introduced dependency like so:
```
cargo tree --no-default-features --features rustls-tls -i openssl-sys
```
This commit puts the OpenSSL dependency behind the native-tls feature
flag again.
You can check the TLS features like so:
```
cargo check --workspace --all-targets --features vendored-openssl
cargo check --workspace --all-targets --all-features
cargo check --workspace --all-targets --no-default-features --features rustls-tls
```
Maybe this should be added to CI. But I don't want to waste anybody's
time.
* Check feature flags during CI
Adds a new CI job 'check-feature-flags' to verify the following:
- Lychee with rustls-tls feature only doesn't depend on OpenSSL
- Cargo check passes with default features
- Cargo check passes with all features
- Cargo check passes with rustls-tls feature only
Skipping URLs in verbatim elements didn't take nested
elements into consideration, which were not verbatim.
For instance, the following HTML snippet would yield
`https://example.com` in non-verbatim mode, even if
it is nested inside a verbatim `<pre>` element:
```html
<pre><a href="https://example.com">link</a></pre>
```
This commit fixes the behavior for both `html5gum` and
`html5ever`.
Note that nested verbatim elements of the same kind
still are not handled correctly.
For instance, the following HTML snippet would still yield
`https://example.com`:
```html
<pre>
<pre></pre>
<a href="https://example.com">link</a>
</pre>
```
The reason is that we currently only keep track of a single
verbatim element and not a stack of elements, which we
would need to unwind and resolve the situation.
Fixes https://github.com/lycheeverse/lychee/issues/986.
I don't see the reason why publish-check has to wait for the other jobs to complete. After all, it's yet another "lint".
Running it in parallel might shave of a significant amount of time from our CI builds.
crates.io sometimes takes a bit until new releases
are available through the API.
This can break the binary release because it depends
on the lychee binary. Therefore let's wait a bit
instead of immediately publishing to reduce
the risk that this is happening.
Since github.repository_owner refers to the base repository on pull request events, while secrets need to exist on the head repository, the Docker Hub login fails for pull requests opened from forks. This commit assures that this step in case of pull request events only runs for internal pull requests, i.e. when head and base repository are the same.
For the actual Docker Hub upload, no change is required: The build can run in every case, the upload is not done on pull request events in general.
Signed-off-by: MichaIng <micha@dietpi.com>
