build: move to GitHub Actions workflow(s)

[vinayakkulkarni]

• Enabled dependabot for dependencies check
• Enabled automerge workflow for merging dependabot PRs
• Enables CI check(s) on any PR to master – will move to new PR
• Enables CT check(s) on any PR to master – will move to new PR
• Enabled Automated publishing the tileserver-gl docker image on dockerhub – will move to new PR

Signed-off-by: Vinayak Kulkarni 19776877+vinayakkulkarni@users.noreply.github.com

[vinayakkulkarni]

I think this would be a very good value add @petrsloup

[acalcutt]

Is there a preference for ghcr.io of dockerhub? The old packages were publicked to dockerhub weren't they?

I like the dependabot setup, I think that is needed

In my forks workflow I have made it so pushes on main trigger testing, a automated version bump, then they published a "latest" and "versioned" docker so a user could pick a particular version if they wanted, and publish to npm. Do you think something like that would be useful here?
https://github.com/acalcutt/tileserver-gl/blob/main/.github/workflows/Build_Test_Release.yml

[vinayakkulkarni]

https://github.com/acalcutt/tileserver-gl/blob/main/.github/workflows/Build_Test_Release.yml#L65-LL66

1. why add (secrets) credentials for Docker when GITHUB_TOKEN works fine out-of-the-box for ghcr.io
2. many folks have moved from dockerhub to ghcr.io as the default container registry
3. granular control of the permissions (which is lacking in dockerhub & available if you pay them $$$)
4. ghcr.io is always free and unlimited for public repos

[acalcutt]

Makes sense. I'm not sure if there is a preference here, I was just wondering. If the docker images were moved to ghcr.io it would require a documentation update right?

[pgassmann]

I prefer dockerhub. It is the default registry and where I search if software is available as a docker image. I don't even see how I can search ghcr.io for images. Until now I did not hear about projects moving to ghcr.io. But that's just my perspective.

[vinayakkulkarni]

Ok, I've removed the auto-publishing to registry for now, this just has CI & CT along with Dependabot.

[acalcutt]

I tested this on my fork to see what to expect, but it failed due to missing prettier. I assume this needs your other linting PR?

[vinayakkulkarni]

I tested this on my fork to see what to expect, but it failed due to missing prettier. I assume this needs your other linting PR?

Yes, since we don't have any lint tools in-built, the prettier checks will fail, I've commented it out that step in this PR but once we merge #596, I can send in another PR for enabling ESLint & Prettier checks in CI.

[acalcutt]

have you tried this at all on a protected branch? I feel like the automerge portion of this could have trouble when a review is required for commit.

[vinayakkulkarni]

have you tried this at all on a protected branch? I feel like the automerge portion of this could have trouble when a review is required for commit.

I have replicated the automerger from https://github.com/nodejs/undici/blob/main/.github/workflows/nodejs.yml#L26-L38 but haven't tested it on protected branch, will test and let you know.

[vinayakkulkarni]

have you tried this at all on a protected branch? I feel like the automerge portion of this could have trouble when a review is required for commit.

I have replicated the automerger from nodejs/undici@main/.github/workflows/nodejs.yml#L26-L38 but haven't tested it on protected branch, will test and let you know.

vinayakkulkarni#1

Protected branches are automerged as well.

[vinayakkulkarni]

@acalcutt: Can you please re-review? I've kept CodeQL workflow cause that will help us catch all security risks in the project as that should (would) be the highest priority for making it production ready for everyone :)

[acalcutt]

Maybe we should put back the CT workflow in some form too. On the PRs it was nice having a testing workflow to help decide if a PR should be merged. ... even it its just in a workflow of its own instead of a pipeline.

[vinayakkulkarni]

Maybe we should put back the CT workflow in some form too. On the PRs it was nice having a testing workflow to help decide if a PR should be merged. ... even it its just in a workflow of its own instead of a pipeline.

Agreed, I will raise another PR for integrating CT & CI workflow once this PR is merged?

I was also thinking of introduction ship.js for automated releases as I see you're manually adding git tags etc which is a pain for a single developer, with ship all that meta stuff is handled automatically by the library