build: move to GitHub Actions workflow(s)

[vinayakkulkarni]

• [x] Enables CI check(s) on the PR
• [x] Enabled dependabot for dependencie(s) check
• [x] Enabled automerge workflow for merging dependabot PRs
• [ ] Enabled Automated publishing the tileserver-gl docker image on ghcr.io | dockerhub (in another PR)

Signed-off-by: Vinayak Kulkarni [email protected]

[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.

https://github.com/vinayakkulkarni/tileserver-gl/pull/1

Protected branches are automerged as well.

[acalcutt]

I tried this again in my fork and I'm not sure this is something I can approve without getting more permissions to set this up properly.

I do want dependabot, so if you wanted to submit a PR for that I think that would be great (start slow)

For the pipeline, The CT portion works fine, but the CI is failing at the linting stage. I think the issue is, like here, I have branch protection enabled and reviews required, so it is not able to write back the changes.

I also ran into issues with the versioning inside the dockerfile. My build did not find the version specified in the file and failed. I am building for multiple platforms (amd64/arm64) there, so maybe it relates to that. (though I would think if that were the case it would fail on arm64 and not amd64 like it seems to be doing) .

[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