Skip to content

Conversation

fghoussen
Copy link
Collaborator

Pull request purpose

fixing CI that seems broken again... help would be appreciated here...
Top priority PR: no CI (arms), no merge (chocolate)...

@fghoussen
Copy link
Collaborator Author

CentOS seems definitely dead! @sylvestre : kill? Or try to replace it with RedHat https://faun.pub/how-to-build-rhel-based-docker-images-on-redhat-enterprise-linux-def012f84890?

@sylvestre
Copy link
Contributor

yeah, red hat sounds great

@fghoussen
Copy link
Collaborator Author

basic redhat podman test: https://access.redhat.com/solutions/3696691

@fghoussen
Copy link
Collaborator Author

Are Github actions broken? Commits are not seen on opencollab?!...
https://github.com/opencollab/arpack-ng/actions/runs/1820338627 => opencollab side: centos should be deleted ?!
https://github.com/fghoussen/arpack-ng/actions/runs/1820338492 => my side: redhat test OK

What's going on? Any help/clue is appreciated here

@fghoussen
Copy link
Collaborator Author

Brilliant?!... pull_request does not see secrets anymore, so docker jobs are down...

@fghoussen
Copy link
Collaborator Author

On PR, commit is stuck at master: PR'ed code is not tested...

@fghoussen
Copy link
Collaborator Author

OK, so, seems that pull_request_target use master as a reference such that PR'ed branch can use secrets (belonging to master) and make docker build OK, but, does not checkout PR branch so the code modified by the PR is actually not tested?!?!... Using pull_request break docker anyway (no access to secrets - docker login/password - in master).

So I'll cut this PR in 2 parts : fix-ci and fix-github-actions. fix-github-actions has a checkout on ${{github.ref}} hoping this makes PR run on PR'ed branch : fix-github-actions will have to be yet another blind-push... No better than this at the time: help is appreciated.

@fghoussen
Copy link
Collaborator Author

Now #343 is merged... Maybe this PR will test the code modified by this PR?!... Rebasing on master...

@fghoussen
Copy link
Collaborator Author

@sylvestre : #343 didn't help. Do you know how to fix this?

@fghoussen
Copy link
Collaborator Author

fghoussen commented Feb 13, 2022

Check commit is OK

commit a40e66c6c6aa68fac4e97c6aca9992dedb1826c4
Author: Franck HOUSSEN <***@users.noreply.github.com>
Date:   Sun Feb 13 13:22:23 2022 +0100

    run travis_redhat.

But still does not run docker_redhat instead of docker_redhat (which should eb renamed podman_redhat BTW!) ?!...

@fghoussen
Copy link
Collaborator Author

redhat still fails?!... The check commit stage points out the correct commit from the correct repo/branch (the PR' ones), but, the job is the one from master?! @sylvestre : ring a bell?

@fghoussen
Copy link
Collaborator Author

@sylvestre: PR does not run code from PR'ed branch but the one from master?! PR changes are not tested?!

@fghoussen
Copy link
Collaborator Author

Same problem: PR is not tested, ea1dfe7 (master) is ran, not b5c02b0 (PR). No solution. any help is welcome @sylvestre ?

@fghoussen
Copy link
Collaborator Author

fghoussen commented Mar 14, 2022

@sylvestre: my understanding (I may be wrong) is that we must drop all docker/podman (redhat) jobs, switch back to pull_request... Test the new workflow and hope for it to work as expected...

  • To run docker jobs we now need login/password. These login/password are stored as secrets in opencollab user: any user who would PR can not access them, so all docker builds are KO.
  • To access them, we need to trigger CI on pull_request_target instead of pull_request: this allows any user who would PR to run in 'the env of opencollab master with secrets as env variables' so docker jobs can run... But it seems that the commit is stuck on opencollab master (ea1dfe7) but not the one the CI is supposed to test (= b5c02b0 = commit of the PR => check out podman_redhat job : the job ran is the one from opencollab master, not the one the PR intend to modify).

Not sure to know how to get out of this mess... Switching back to pull_request will prevent docker to run, and, I'am not even sure this would make things back as expected (= CI testing the code modified by the PR!)

https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

@sylvestre
Copy link
Contributor

not sure what you mean?!
many jobs seems to work
just disable the failing jobs?
it is probably good enough

@fghoussen
Copy link
Collaborator Author

fghoussen commented Apr 2, 2022

Less and less time for that...

As is jobs does not work: #341 (comment)

Only solution I see:

  1. drop all docker-like jobs (free the workflow from use of secrets - mandatory for docker login)
  2. return to pull_request (do not use pull_request_target that seems to make the workflow based on master)
  3. test the resulting pull_request workflow (without docker-like jobs and no need for secrets)
  4. make sure the code of a PR is indeed tested by the PR (= PR test the code modified - this is no more what happens!).

This means getting back to CI when done on TravisCI with only distro offered by Travis. Sounds to me like the only way. Not sure if there is a better way

@sylvestre: OK ?

@sylvestre
Copy link
Contributor

sylvestre commented Apr 2, 2022 via email

@fghoussen
Copy link
Collaborator Author

OK. If you're OK, I'll try to fix the workflow this way when possible (not much time for now).
The workflow is now broken: when one PR, it seems that the code of master is ran (not the one of the PR)... Looks related to the fact that with github actions, all is done to avoid/limit/prevent malicious actions: so simple things are no more simple...

@fghoussen
Copy link
Collaborator Author

@sylvestre : drop coverage? Never works with github-actions (but did with TravisCI)

Mac with cmake KO: not mac-based, can somebody help? @prj-: any clue?

[ 99%] Building C object CMakeFiles/icb_parpack_c.dir/PARPACK/TESTS/MPI/icb_parpack_c.c.o
clang: error: unknown argument: '-fallow-argument-mismatch'

@prj-
Copy link
Contributor

prj- commented Apr 10, 2022

Where is -fallow-argument-mismatch coming from? It should only be set for the Fortran compiler.

@fghoussen
Copy link
Collaborator Author

Where is -fallow-argument-mismatch coming from?

No idea! On github-actions boxes, seems that gcc can not be installed (pkg conflicts): gfortran is used for fortran and clang for C/C++

It should only be set for the Fortran compiler.

I know! Not mac-based and not so familiar with it. This is why I tried f36b044. If you have any clue, would be nice :)

@fghoussen
Copy link
Collaborator Author

@sylvestre: are you OK with 0ba37a7?

@fghoussen
Copy link
Collaborator Author

OK, my understanding is that problems have been passed for C/C++ with gfortran/clang, but, we hit now same problems for MPI (parpack).

[ 99%] Building C object CMakeFiles/icb_parpack_c.dir/PARPACK/TESTS/MPI/icb_parpack_c.c.o
clang: error: unknown argument: '-fallow-argument-mismatch'

@fghoussen fghoussen merged commit 19a08ec into opencollab:master Apr 10, 2022
@fghoussen fghoussen deleted the fix-ci branch April 10, 2022 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants