myoldmopar / decent_ci Goto Github PK

I think I fixed the folder not being able to be deleted issue, but it doesn't seem the rm -rf solution wants to work on windows. We can hopefully go to more rubyic ways of deleting folders now.

I tried adding a new build for GCC 7.3.0 to test on an Ubuntu 18.04 VM. I just copied and pasted one of the 4.8 versions. I found when debugging decent that it was raise an exception if it couldn't find the appropriate compiler, but that exception would raise it all the way up to the branch loop. So any other suitable builds for that branch wouldn't be run.

Decent ci should also skip if [skip ci], [ci skip], [no ci] are present, so that one could skip both actions and decent ci with those.

cf https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

In a number of cases, the actual branch has been deleted before CI gets to it, yet CI still had it on the current punch list. So CI goes ahead and builds the baseline before realizing the branch can't be built, and it fails. Just check to make sure the branch can be built before building the baseline.

It can't find the redist directory for visual studio 2019. Need to set MSVC_REDIST_DIR to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.20.27508", then it will append "x86/Microsoft.VC141.CRT" to it to make the MSVC_CRT_DIR variable valid, and it will then find the concrt140.dll file it is looking for.

Right now it runs if it finds a potential valid build but it's already run:

I turned on skip_regressions for a branch in the yaml file. Therefore Decent CI didn't try to pull the baseline and build it. However, I didn't delete the CMake variables for doing regressions (-DENABLE_REGRESSIONS, etc.) Then when it built the branch, the CTests were added to do regression comparisons. These silently passed because the baseline was missing from each. This is expected because we don't throw warnings when new test files are added, etc. However, the baseline failed without giving any warning, this should do something...

In addition to skipping by commit message, I'd also like to check the labels on open PRs to see if the dev has set it to "no ci" or something. That will keep people from having to constantly add ci flags to every commit including merge commits.

If develop is out of date, it doesn't show up in the potential build list, and then the CI setup can't assign it as the baseline, so things don't work.

Get it hooked back up with Travis, all three platforms, start with something easy: the num processor function.

Clang was failing to configure because it adds some default compiler flags when it can't pick up the right compiler. Ultimately this was caused because the cc and cxx weren't being searched because the version was not specified, and Decent CI required it. The search function actually allows for it to be missing, and if it is missing, it tries to just find one without a specific version. However, we were exiting too early and not even trying to search for it. Just eliminate that loophole. We are required to specify a version on Windows with Visual Studio, so no issue there. And the GCC builds already specify a version, so it shouldn't affect those. Hopefully it will be a quick, painless fix that will get Mac working well.

Add a dash flag that can be passed in and will override the num_processors value. The num processors can be specified in the compiler yaml, but that doesn't allow it to be different on different CI instances.

Move cppcheck parser to cppcheck.rb, etc.

Having the ability to look at the entire log when a cmake configure or a build step fails would be great.

Even having to retrieve those "manually" from s3 would be nice.

On external PRs, the dashboard shows the branch name, and also the PR number, both as links. The branch link works fine and goes to the external repo. The PR has a mistake -- it should actually go to the target repo (NREL/EnergyPlus).

Should we?

Right now, decent ci creates a list of all potential builds, which can take quite a while, then when looping over the potential build list later, applies the environment variables for compiler and branch filter. I think we should be able to apply the branch filter earlier and save time.