Skip to content

Conversation

@stertooy
Copy link
Contributor

  • Turn more steps into separate scripts that are now tested in CI (see Split out some of the more complex steps into separate files and add tests #27)
  • Move all scripts to a folder.
  • Replace GAP Error by Exec("echo \"::error:: [...] \""); FORCE_QUIT_GAP(1); to make the errors more visible in GitHub Action logs.
  • Validate inputs when relevant (like in run-pkg-tests).
  • Made indendation consistent (2 spaces per level).

if not IsBound(GAPInfo.PackageInfoCurrent) then
Print("Reading PackageInfo.g failed\n");
FORCE_QUIT_GAP(2);
Exec("echo \"::error::Reading PackageInfo.g failed\"");
Copy link
Member

Choose a reason for hiding this comment

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

This file is a GAP "script", I mean, we can easily treat it as script with GAP as execution environment, but in general I'm not a big fan of including Actions logic into GAP.

Writing an abstraction layer could be helpful.

@fingolfin What do you think?

Copy link
Member

Choose a reason for hiding this comment

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

I guess we could have a file gh_actions.g which contains code that re-defines Error to do something else (e.g. call Exec like here), and then change e.g.

gap -A -q $GITHUB_ACTION_PATH/scripts/pkginfo_to_json.g

to

gap -A -q $GITHUB_ACTION_PATH/scripts/gh_actions.g $GITHUB_ACTION_PATH/scripts/pkginfo_to_json.g

But I am not sure it's worth the trouble? After all, you can run pkginfo_to_json.g locally even with that Exec for errors in it.

Copy link
Member

Choose a reason for hiding this comment

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

I.e. I am not sure what another abstraction layer would gain us, what benefit it would bring? Its downside is the usual: it adds complexity and thus opportunity for new bugs, and makes debugging harder.

(I am not saying there are no issues, just that I don't see them; happy to learn)

Co-authored-by: Kamil Zabielski <50334623+limakzi@users.noreply.github.com>
Comment on lines +125 to +132
if ! ./check_date.sh "$(date +%Y-%m-%d)" \
|| ! ./check_date.sh "$(date -d "1 day ago" +%Y-%m-%d)" \
|| ! ./check_date.sh "$(date -d "1 day" +%Y-%m-%d)" \
|| ./check_date.sh "$(date -d "2 days ago" +%Y-%m-%d)" \
|| ./check_date.sh "$(date -d "2 days" +%Y-%m-%d)"
then
exit 1
fi
Copy link
Member

Choose a reason for hiding this comment

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

Doesn't GitHub run scripts with set -e anyway? Then we could just do this, and get better info about which check failed:

Suggested change
if ! ./check_date.sh "$(date +%Y-%m-%d)" \
|| ! ./check_date.sh "$(date -d "1 day ago" +%Y-%m-%d)" \
|| ! ./check_date.sh "$(date -d "1 day" +%Y-%m-%d)" \
|| ./check_date.sh "$(date -d "2 days ago" +%Y-%m-%d)" \
|| ./check_date.sh "$(date -d "2 days" +%Y-%m-%d)"
then
exit 1
fi
! ./check_date.sh "$(date +%Y-%m-%d)"
! ./check_date.sh "$(date -d "1 day ago" +%Y-%m-%d)"
! ./check_date.sh "$(date -d "1 day" +%Y-%m-%d)"
./check_date.sh "$(date -d "2 days ago" +%Y-%m-%d)"
./check_date.sh "$(date -d "2 days" +%Y-%m-%d)"

Copy link
Member

Choose a reason for hiding this comment

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

@fingolfin I prefer your syntax.
I think GitHub does, but its for testing, I suppose.

Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

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

I am in favor of merging this (and tagging it so it gets use) rather sooner than later.

@fingolfin fingolfin merged commit a2750b8 into gap-actions:main Nov 25, 2025
3 checks passed
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