Skip to content

Drop call to escape_non_unicode_symbols #1357

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

nsoranzo
Copy link
Member

@nsoranzo nsoranzo commented Mar 1, 2023

which was removed from allure-python-commons in 2.13.0 .

Alternative to #1356 .

which was removed from allure-python-commons in 2.13.0 .
@nsoranzo
Copy link
Member Author

nsoranzo commented Mar 1, 2023

Looking at the error message, I think the failing test is due to galaxyproject/galaxy#15497 , ping @nuwang .

@mvdbeek
Copy link
Member

mvdbeek commented Mar 1, 2023

I'll go ahead and merge this anyway, since I think this break a lot of CI pipelines.

@mvdbeek mvdbeek disabled auto-merge March 1, 2023 15:56
@mvdbeek mvdbeek merged commit aea0bf0 into galaxyproject:master Mar 1, 2023
@mvdbeek
Copy link
Member

mvdbeek commented Mar 1, 2023

Thanks @nsoranzo!

@nsoranzo nsoranzo deleted the drop_escape_non_unicode_symbols branch March 1, 2023 16:00
@nuwang
Copy link
Member

nuwang commented Mar 13, 2023

@nsoranzo I just spotted this message. Is there an issue related to galaxyproject/galaxy#15497?

@nsoranzo
Copy link
Member Author

Hi @nuwang , thanks for getting back! Yes, I think so, see this test run (line 2546): https://github.com/galaxyproject/planemo/actions/runs/4365276747/jobs/7633682776#step:8:2547

galaxy.tool_util.provided_metadata INFO 2023-03-08 14:56:58,940 [pN:main.1,p:10159,tN:LocalRunner.work_thread-0] One or more tool outputs is marked as failed ({'type': 'dataset', 'ext': 'data', 'dataset_id': 1, 'stderr': 'Unable to fetch file:///home/runner/work/planemo/planemo/tests/data/hello.txt\nCould not find handler for URI [file:///home/runner/work/planemo/planemo/tests/data/hello.txt]', 'failed': True}).

It seems the file:// protocol is not correctly handled. If you can take a look, that would be great!

@nuwang
Copy link
Member

nuwang commented Mar 14, 2023

I think I see where the issue is originating from and adding file:// as a supported protocol should restore previous behaviour. I'll create a PR with a fix.

@nsoranzo
Copy link
Member Author

I think I see where the issue is originating from and adding file:// as a supported protocol should restore previous behaviour. I'll create a PR with a fix.

That's great, thanks @nuwang !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants