-
Notifications
You must be signed in to change notification settings - Fork 274
[CI] Remove codebuild configuration. #5536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming that we have all of the same platform / configurations for building in the github CI as codebuild -- sure! I know this wasn't the case when moving from Travis to codebuild.
That said -- why is codebuild being run on this PR? |
@martin-cs It's not being run - it's being triggered because it's hooked into the repository's settings, but because of the config being removed, it's hanged. I have asked @peterschrammel to review it, and if he thinks it's good, to review the required status from these checks, so they are no longer there. This isn't new - same thing happened when we removed travis :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which are the mandatory jobs now?
The codebuild jobs include a Linux + clang compiler build, which as far as I can see hasn't been ported to git hub actions yet. I think there may be value in porting this over, before we abolish code build. A Linux + clang compiler job may be useful for isolating whether build failures on mac are due to using the Clang compiler or due to the standard library versions they use. In addition, the error messages from Clang can sometimes be easier to read than the ones from gcc. |
Okay, #5559 was now created to introduce the missing build to github actions, so we now all previous codebuild jobs should be ported to github actions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm completely wrong here, but wouldn't we lose the Codecov integration? I'm not sure which of the two buildspec-linux-*-gcc-cov.yml is currently taking care of this, but they might still be needed?
Since we have now implemented most jobs on github actions, it makes sense to depend on that and remove codebuild, as this has multiple benefits: 1) It makes it easier for project contributors to see the result of the builds of their PRs (in codebuild, it was very complicated to access the build results, and as a matter of fact we had special instructions for accessing them). 2) It removes the maintenance burden from us to maintain multiple CI systems, especially since there are not obvious benefits to doing so. 3) We no longer need to have so many jobs needed for one PR, which used to create multiple problems, as it was the case that some jobs would always fail in some way (like fail to be initialised).
fe7b735
to
2d3a5b7
Compare
Codecov Report
@@ Coverage Diff @@
## develop #5536 +/- ##
===========================================
+ Coverage 72.84% 72.86% +0.01%
===========================================
Files 1421 1421
Lines 154138 154171 +33
===========================================
+ Hits 112289 112331 +42
+ Misses 41849 41840 -9
Continue to review full report at Codecov.
|
@tautschnig Hi Michael, can you take another look at this? We have ported almost all of the jobs to GitHub Actions now (the ones missing are ones based on outdated configuration, like clang-3.8, and some windows setups like building under Does this look more fit for purpose now? |
Since we have now implemented most jobs on github
actions, it makes sense to depend on that and remove
codebuild, as this has multiple benefits:
see the result of the builds of their PRs (in
codebuild, it was very complicated to access
the build results, and as a matter of fact we
had special instructions for accessing them).
multiple CI systems, especially since there are not
obvious benefits to doing so.
PR, which used to create multiple problems, as it was
the case that some jobs would always fail in some way
(like fail to be initialised).