Build native libs from CI

[gotson]

Hi @xerial,

i have recently added support to build Mac arm64 (M1) native library through Docker.

Being able to compile all the platforms through Docker opened the door to build all the native libs from CI (workflow, documentation).

It's been working well, and we can do 2 things:

• trigger on a PR via a comment (/native), which will commit the new libraries back to the PR branch
• trigger manually via the Github UI, which will commit the new libraries back to the selected branch

However i noticed that the commit with the new libraries doesn't trigger CI, this is due to this.

You can see that it failed for a PR here:

And on the master branch here:

In order for this to work, we need to configure a Personal Access Token in the repository's secrets, and use it instead of the default GITHUB_TOKEN secret.

@xerial would you be open to create a PAT with the repo scope, unlimited expiry, and add this to the repo secret under the key name PERSONAL_TOKEN ?

Once done i can modify the existing workflow to use this token instead of the default.

Thanks !

[gotson]

@xerial sorry to ask again, but would you be open to add a personal access token in the secrets, so we could trigger CI after native libs are built and committed from CI?

[xerial]

@gotson Hi. I just noticed this message. Do you still need a new token for this?

[gotson]

Yes, that would help!

[xerial]

I want to use a new fine-grained personal access token (beta) to limit access only to sqlite-jdbc, but I'm not sure what permissions are necessary. Could you suggest what read/write permission need to be granted?

I guess read/write pull requests, access repository contents (read-only?), triggering other GitHub action (read only would work?), etc.

• Sharing PAT is not recommended because it provides access to my other repositories as well https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token#keeping-your-personal-access-tokens-secure
• Fine-grained access token https://docs.github.com/en/rest/overview/permissions-required-for-fine-grained-personal-access-tokens

[gotson]

Using a new fine-grained PAT is a good idea indeed.

I think the permissions should be:

• Contents - read/write
  • to access the commits/branches, doing a checkout with https://github.com/actions/checkout
  • push a new commit, using https://github.com/EndBug/add-and-commit
• Metadata: read. Apparently required to perform a checkout, according to this comment.
• Pull requests: read/write. The workflow can commit to the upstream repo directly, i think we would need that permission.