kykrueger commented on PR #1806:
URL: https://github.com/apache/systemds/pull/1806#issuecomment-1519063603
Looks like the workflow is failing because of a github action I was calling
to delete all of the artifacts no longer needed at the end of the job. I'll
write something myself in the workflow instead of calling that project.
Anyhow, to your points:
> Sure we can make this change.
Personally i kind of like that we automatically keep up to date tho, but
running both latest and 22.04 for all tests would be to much. If we can design
it in such a way that all tests run on 22.04 and a subset (maybe applications
only) run on latest then that would be cool, but only run the latest version if
latest is different than 22.04.
> In general that all seems like to much work compared to just having
everything run on latest, also worth noting is that latest only update once
every 2 years. so not a big concern in my opinion.
Fair enough, it is just a preference, we can leave it on latest. It will
just be important to keep that in mind as a possible source of test-failure if
anything funny happens.
>> The applications-tests do not use setup-java and therefore use the
default java installation of ubuntu-22.04, so if not replacing ubuntu-latest
with a fixed version, I'd at least want to add a fixed version with setup java,
but maybe even pin both a version for java and ubuntu.
> This sounds like a bug on my side, feel free to make a minor PR for it.
Will do
> The reason they were split was to give nice names on the UI when the tests
were run to clearly indicate what tests were executed. the component.a** is not
really quickly understandable.
Maybe if you want to combine with point 2 as a minor thing, and combine all
in a single workflow to reduce the code duplication but we still want some way
if clearly understanding what test is run in each workflow.
I'll see if I can come up with a way to clean up the names. If not I'll
leave the test-groups separated as they were.
> I think you did a fine medium of 30 days, my only concern is that the
artifact is 54.8 MB perhaps there is a way to compress this?
or/and set a dynamic retension of only last 30 days on main branch and 7 on
PRs?
This concerns me because it can grow very quickly with a few commits filling
way to much.
I'm not sure about the billing for the artifacts and their size, but github
actually already compresses the directory to a zip. This reduces the size to
around 12.5 MB, and I think it would be cheeky for them to charge for the
decompressed file size, but I can check their docs for more info. If there is
no info about that in the docs and you are keen, we could pre-compress the
directory to be sure. Otherwise, we we could reduce the size to under 1 MB
(before compression) by just keeping the CSV with all the summarized results.
As for the test coverage, you can see it in my fork for now until I remove
that action call.
https://github.com/kykrueger/systemds/actions/runs/4769263418
The line coverage has 193,435 of 794,773 instructions missed (75% coverage)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@systemds.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
