Ensure dotfiles are also included in release archives

[stertooy]

Resolves #55

[james-d-mitchell]

This'll work to resolve my issue, not sure if it might have further implications I'm not aware of though. Thanks @stertooy

[stertooy]

The current situation is a bit contradictory, since using cp -r * target doesn't copy dotfiles in the current directory, but does copy over dotfiles from subdirectories. And we also do some cleanup that includes a lot of dotfiles (which weren't copied over anyway):

release-pkg/action.yml

Lines 148 to 157 in db30629

	echo "::group::Cleanup git and github related files"
	rm -rvf .git* .hg* .cvs* .circleci
	echo "::group::Cleanup codecov, travis, azure-pipelines"
	rm -fv .codecov.* .travis.* .appveyor.* azure-pipelines.*
	rm -fv .gaplint.*
	rm -fv requirements.txt
	echo "::group::Cleanup macOS metadata"
	find . -name .DS_Store -exec rm -f {} +

Perhaps we should just choose a particular route to take w.r.t. dotfiles:

1. Never add them to a release by default, but provide an input that lets users specify dotfiles to explicitly add
2. Copy them over by default, unless it's on our "removal list" (i.e. the code above).

Personally I'm more a fan of option 2. I'd prefer to have this action create functional releases with no extra effort for authors, at the cost of perhaps some unneeded dotfiles slipping through.

[james-d-mitchell]

I also prefer 2, but I am obviously biased in this case :)

[james-d-mitchell]

@fingolfin any reason to not merge this?

[limakzi]

LGTM.

[fingolfin]

Note that the dotfile cleanup is taken from my old release tool scripts. That one did not copy files over via cp -r. Instead it used git archive to get a fresh snapshot of the git worktree, and then rummaged around in that.

Anyway, I have no objections to this PR (though, should it Close #55 maybe?)