Github actions for testing the template

[kubukoz]

http://www.foundweekends.org/giter8/testing.html#Using+the+Giter8Plugin

https://github.com/djspiewak/sbt-github-actions/

[kubukoz]

This would be super nice now.

[TonioGela]

sbt-github-actions is great for producing github actions to publish a library, probably there will be the need to trim down the ci.yml that produces (at least to remove the publish part).

What is the intended behaviour btw? Scripted-tests should occur at every push nevertheless it's a PR or not? Asking for a friend :P

[kubukoz]

Yeah, I think that's the plan.

I think you can just disable publishing indeed, and use scripted as the command, should be good enough. We probably don't need too many combinations of the settings either :)

[TonioGela]

I just pushed a PR, but there are a few thing to be noted:

1. I left the sbt-github-actions plugins in the g8 project since it can be useful in the future if the GH actions plugins get updated.
2. The same plugin filled the matrix just with

os: [ubuntu-latest]
scala: [2.12.13]
java: [adopt@1.8]

since these are the only settings that can be extrapolated from the g8 project itself. We can decide to force at least the latest 2.13.x version in the "outer" project
3) I can't say if the clean.yml is useful atm, and same for the GITHUB_TOKEN env variable too.
4) The "testing action" that is performed is not sbt scripted but sbt g8Test
5) The test is not a mere > test but it checks for the existence of the files that should be created
6) AFAIK there's no way to test a template with property values different from the default ones, so the scala3 "branch" doesn't get tested

@kubukoz I ask your opinion about 2 & 3 in particular

[kubukoz]

I'm not sure why we can't leave sbt-github-actions and githubWorkflowCheck? I was thinking of keeping that plugin in use, so that when any updates happen we'd have to make sure the workflows are up to date. Just having the plugin dependency isn't quite like it.

About #2, I would use the version from the build, I'm not sure it even matters since the outer project doesn't contain sources of its own.

3. I can't say if the clean.yml is useful atm, and same for the GITHUB_TOKEN env variable too.

The caching/cleaning setup is probably worth having even if you don't publish. I've done that before.

4. The "testing action" that is performed is not sbt scripted but sbt g8Test

Yeah, I didn't know it was a different task. Looks good

5. The test is not a mere > test but it checks for the existence of the files that should be created

looks good

6. AFAIK there's no way to test a template with property values different from the default ones, so the scala3 "branch" doesn't get tested

That's weird but acceptable, we can live with that for now ;)

[TonioGela]

I'm not sure why we can't leave sbt-github-actions and githubWorkflowCheck? I was thinking of keeping that plugin in use, so that when any updates happen we'd have to make sure the workflows are up to date. Just having the plugin dependency isn't quite like it.

My bad, in fact I haven't tested the githubWorkflowPublishTargetBranches := Seq() way to avoid the publishing step and I thought that setting it would have removed just the publish step leaving the artifact upload in the build one. So what I did was just manually removing those steps and the githubWorkflowCheck (that wasn't passing in fact).

The caching/cleaning setup is probably worth having even if you don't publish. I've done that before.

Looking better at the README.md of sbt-github-actions:

clean.yml is generated based on a static description because it should just be the default in all GitHub Actions projects. 
This is basically a hack to work around the fact that artifacts produced by GitHub Actions workflows count against personal
and organization storage limits, but those artifacts also are retained indefinitely up until 2 GB. This is entirely unnecessary
and egregious, since artifacts are transient and only useful for passing state between jobs within the same workflow. 
To make matters more complicated, artifacts from a given workflow are invisible to the GitHub API until that workflow is 
finished, which is why clean.yml has to be a separate workflow rather than part of ci.yml. It runs on every push to the repository.

probably this testifies that in this particular case artifact cleaning is not useful, but Daniel states that this should be the default for GH Actions, so I agree to leave it there since it can't harm.

[TonioGela]

I think it can be closed now!

[kubukoz]

yeah, if you put Closes #3 in a PR merging it will automatically close the ticket btw :)

[kubukoz]

Closed by #24