[0/4] Add a CI for unsigned char system

Message

Đoàn Trần Công Danh March 3, 2023, 1:46 p.m. UTC

Recently, we have a brokeness on system with unsigned char because most of
people are working with x86_64 which has signed char.

This series tries to add a CI system for a widely used system with signed
char, which is arm64 via circle-ci.

In order to register for git to participate in Circle CI, you need to:
- Create an account and login into Circle CI, (I tried login with GitHub OAuth);
- Register a project with Circle CI, and choose which config.yml we would like
  to be used for Circle CI

Circle CI seems to allow 40000 (Forty thousand credits per month), in my
testing, with resource_class: 'arm.medium', (which costs 10 credits per minute),
it take 12m15s to finish, so that will be about 3000 run per month. I believe
arm.large, which is also available to free accounts and cost 20 credits per
minute, doesn't cost effective but I haven't checked out.

Sample run:
- Without the fix for unsigned char:
  https://app.circleci.com/pipelines/gh/sgn/git/12/workflows/9b39391d-0d03-4669-86e6-2796fd671c43/jobs/10
- Normal run:
  https://app.circleci.com/pipelines/gh/sgn/git/14/workflows/b8745f8e-8a57-4215-847e-2af66c1dd3c7/jobs/12

I'm not really sure if we want the 'store_test_results', which will upload the
test report in the 'TESTS' tab:
https://app.circleci.com/pipelines/gh/sgn/git/14/workflows/b8745f8e-8a57-4215-847e-2af66c1dd3c7/jobs/12/tests
and provides a test insights like this:
https://app.circleci.com/insights/gh/sgn/git/workflows/workflow/tests?branch=circle-ci

Đoàn Trần Công Danh (4):
  ci/lib.sh: remove an useless break
  ci/install-dependencies: libify p4 and git-lfs installation
  ci/install-dependencies: install git-lfs for arm64 build
  ci: add arm64 CI environment via CircleCI

 .circleci/config.yml       | 17 +++++++++++++++
 ci/install-dependencies.sh | 42 ++++++++++++++++++++++++++++++--------
 ci/lib.sh                  | 30 ++++++++++++++++++++++-----
 3 files changed, 75 insertions(+), 14 deletions(-)
 create mode 100644 .circleci/config.yml

Comments

Jeff King March 9, 2023, 9:53 a.m. UTC | #1

On Fri, Mar 03, 2023 at 08:46:02PM +0700, Đoàn Trần Công Danh wrote:

> Recently, we have a brokeness on system with unsigned char because most of
> people are working with x86_64 which has signed char.
> 
> This series tries to add a CI system for a widely used system with signed
> char, which is arm64 via circle-ci.

I like the overall goal, but I'm not wild about having another CI
provider. That requires people logging in there, and then dealing with
possible credit overages, etc.

I wonder what the timeline is for GitHub Actions getting arm64 support.
It looks like there are images for linux/arm64, but no runners yet,
according to:

  https://github.com/actions/runner-images/issues/5631

You can point it at your own runners, and some people in that thread
mentioned a third-party service which provides arm machines. That
doesn't get out of the "oops, credits" handling, but it would at least
keep the CI results all together.

I dunno. Another option I saw suggested is using qemu within a regular
GitHub runner. I have no idea if that would be painfully slow or what,
but it looks like people have even written actions to handle it:

  https://github.com/docker/setup-qemu-action

-Peff

Chris Torek March 9, 2023, 10:26 a.m. UTC | #2

On Thu, Mar 9, 2023 at 1:54 AM Jeff King <[e-mail]> wrote:
> I like the overall goal, but I'm not wild about having another CI
> provider.

So, why not do an x86 build with `-funsigned-char`? Seems to work with
both gcc and clang.

Chris

Jeff King March 9, 2023, 10:57 a.m. UTC | #3

On Thu, Mar 09, 2023 at 02:26:34AM -0800, Chris Torek wrote:

> On Thu, Mar 9, 2023 at 1:54 AM Jeff King <[e-mail]> wrote:
> > I like the overall goal, but I'm not wild about having another CI
> > provider.
> 
> So, why not do an x86 build with `-funsigned-char`? Seems to work with
> both gcc and clang.

Yeah, that would be even simpler. Though IMHO "unsigned char" is only
one interesting difference to be checking. Another would be having a
platform where unaligned access isn't tolerated. It would be nice to
have a big-endian platform, too, but I'm not sure if arm is a good fit
there (my impression is that it can be run in either mode?).

On the other hand, I think Ævar does periodically run on the gcc build
machines, which includes examples of each (including aarch64). And this
particular bug was found pretty quickly (within a week of it hitting
next, and only a day after hitting master). So while it might be nice to
have more immediate CI feedback, it does seem like the old "if the
platform matters, somebody will try it and report the problem" strategy
still works, too.

-Peff