Skip to content
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

Experiment with testing package distro #78

Merged
merged 5 commits into from
Mar 14, 2022

Conversation

fingolfin
Copy link
Member

@fingolfin fingolfin commented Mar 7, 2022

Status of "failing" package tests: I've moved this overview to an issue of its own, so that I can merge this PR.

@fingolfin fingolfin force-pushed the mh/test-all branch 2 times, most recently from 9216cb3 to cb136e9 Compare March 8, 2022 11:00
Comment on lines +57 to +61
#curl -L -o $HOME/packages.tar.gz ${{ github.event.inputs.pkgarchiveurl || inputs.pkgarchiveurl }}
#ls -l $HOME/packages.tar.gz
#shasum -a 256 $HOME/packages.tar.gz
## TODO: also download and test checksum???
_tools/download_packages.py */meta.json
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how to best "download packages":

  1. using download_packages.py has the advantage that we really test the packages in the commit this action runs on
  2. downloading a packages.tar.gz from a given ensures we really test the tarball we later offer to users; but it requires a download URL for such a package

In practice, I envision that this is run from either ...

  1. a PR workflow (to test whether a PR is ready to be merged),
  2. upon a push to the main branch (to test a packages.tar.gz we just assembled),
  3. as part of a scheduled cron job, to test for regressions introduced in GAP master

For the first scenario, it makes sense to use download_packages.py; for the other two scenarios, I'd say the second approach makes more sense. So perhaps both should be supported, by turning the pkgarchiveurl into an optional argument?

@fingolfin

This comment was marked as outdated.

@fingolfin fingolfin force-pushed the mh/test-all branch 2 times, most recently from 5ac60d3 to 846720d Compare March 9, 2022 16:14
@cdwensley
Copy link

xmod-2.85 and kan-1.34 now released and (hopefully) no longer failing. (Just commented out a few lines in the tests where output differed slightly between gap4r11 and gapdev.)

@fingolfin fingolfin force-pushed the mh/test-all branch 2 times, most recently from d400e22 to 93a9ddc Compare March 13, 2022 14:33
@fingolfin
Copy link
Member Author

kan-1.34 indeed passes its tests now, thank you!

But xmod-2.85 still has diffs, see this log

@cdwensley
Copy link

The problem test, tst/extra/d24.tst, works for me with the latest gapdev. However the log you sent shows 8 versions of packages more recent than the ones installed on my system. So it appears that one of these packages is causing the failure. I have, for now, moved d24.tst to tst/failing; released xmod-2.86; and hope there are no further problems.

@fingolfin fingolfin changed the title WIP: experiment with testing package distro Experiment with testing package distro Mar 14, 2022
@fingolfin fingolfin merged commit fdb01c9 into gap-system:main Mar 14, 2022
@fingolfin fingolfin deleted the mh/test-all branch March 14, 2022 16:50
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.

2 participants