aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/.github/workflows (follow)
Commit message (Collapse)AuthorAge
* workflows/boost_toolsets: simplify the spec furtherEgor Tensin2022-01-07
|
* workflows/boost_toolsets: 3 Boost versions instead of 4Egor Tensin2022-01-07
| | | | Make it not quite that slow.
* workflows: remove Cygwin workflowsEgor Tensin2022-01-07
| | | | | Part of a) simplifying the workflow files and b) reducing the number of jobs. I'll probably add basic Cygwin jobs later.
* workflows/basic: add some commentsEgor Tensin2022-01-07
|
* workflows/boost_toolsets: VS 2022 isn't supported by older BoostsEgor Tensin2021-12-18
|
* support VS 2022Egor Tensin2021-12-15
|
* basic macOS supportEgor Tensin2021-12-15
| | | | | I don't have a Mac to test on, but the knowledge that there is basic support for macOS is still nice.
* workflows/basic: minor fixEgor Tensin2021-10-16
|
* workflows: use -latest images where appropriateEgor Tensin2021-06-19
|
* workflows/basic: test w/ latest PythonEgor Tensin2021-06-11
|
* workflows/basic: test w/ multiple PythonsEgor Tensin2021-05-30
|
* remove the "-" between toolset and versionEgor Tensin2021-05-08
|
* workflows: lint, tweak job names, etc.Egor Tensin2021-05-08
|
* toolset "visual-studio" -> "vs"Egor Tensin2021-05-08
|
* project.toolset: support versioned MSVC toolsetsEgor Tensin2021-05-07
| | | | You can now use something like msvc-141, vs-2017, etc.
* workflows: add run_foo.ps1, compact YAMLEgor Tensin2021-05-04
|
* workflows/basic: tweak step namesEgor Tensin2021-05-04
|
* workflows/basic: run `pip install .`Egor Tensin2021-05-04
|
* project.boost.download: add --no-retry parameterEgor Tensin2021-05-03
| | | | | This is to facilitate testing mostly, but still required substantion refactoring.
* add GitHub workflow to check Boost CDNsEgor Tensin2021-05-03
|
* workflows: use actions/cache@v2Egor Tensin2021-04-24
| | | | The v2 tag was finally bumped to v2.1.5 (I needed v2.1.4).
* workflows: fix cache pathEgor Tensin2021-04-24
| | | | | | | Forgot to switch to $RUNNER_WORKSPACE/build in the workflows also. Also, the usual crap with the cache action made me change the cache keys, or it would be restore in the wrong location for some reason.
* tools: bring back the .py extensionEgor Tensin2021-04-18
| | | | | It should help running the scripts on Windows, where the .py extension is associated with the Python interpreter.
* project.ci: add --hint parameterEgor Tensin2021-04-13
| | | | | This is a stupid workaround for testing other CI systems on GitHub Actions.
* remove excessive logging & obsolete project.ci.* packagesEgor Tensin2021-04-13
| | | | Logging command line arguments before parsing them is a bit excessive.
* tools: drop the .py extensionEgor Tensin2021-04-13
|
* workflows/basic: add job for publishing to PyPIEgor Tensin2021-04-13
|
* workflows/basic: call clang-format.pyEgor Tensin2021-04-05
|
* project.ci: use same variable names for all CIsEgor Tensin2021-03-24
| | | | Using different ones was quite weird to begin with.
* project.ci: change build directoryEgor Tensin2021-03-24
| | | | It's now <source directory>/../build for consistency.
* workflows: fail-fastEgor Tensin2021-03-20
| | | | They are stable enough.
* workflows/basic: enable on windows-2016Egor Tensin2021-03-19
|
* workflows/ci_appveyor: create C:\projects before cachingEgor Tensin2021-03-14
|
* workflows: _really_ fix Boost caching?..Egor Tensin2021-03-14
| | | | | | | | | | | | | | | | | actions/cache@v2 doesn't work on windows-2016 images, since those contain the GNU tar, which cannot work with \ as path separator. This was fixed in package @actions/cache v1.0.5, which is used by action actions/cache@v2.1.4 [1][2]. In addition, it simply couldn't find tar.exe on those images thanks to my action cleanup-path, which removed the corresponding directory (I think it was Git's bin/) from PATH. It worked for windows-2019 images thanks to them containing tar.exe in System32. Solved by turning cleanup-path into a JavaScript action with a "post" step, which restores the original PATH value. [1]: https://github.com/actions/virtual-environments/issues/480 [2]: https://github.com/actions/toolkit/issues/632
* project.ci: cache Boost downloadsEgor Tensin2021-03-13
|
* workflows: fix Boost cachingEgor Tensin2021-03-13
| | | | It seemingly doesn't work unless the key includes runner.os?
* workflows: cache Boost downloadsEgor Tensin2021-03-13
|
* project.ci: auto-fill --toolset from environmentEgor Tensin2021-01-25
|
* project.ci: auto-detect CI systemEgor Tensin2021-01-25
|
* bye-bye, Travis & AppVeyor!no_more_travisEgor Tensin2021-01-19
|
* project.ci: add GitHub ActionsEgor Tensin2021-01-18
|
* project.ci: --install picks the directory automaticallyEgor Tensin2021-01-18
|
* workflows: add Travis/AppVeyor simulationsEgor Tensin2021-01-18
|
* workflows: add "Basic usage"Egor Tensin2021-01-18
|
* workflows: mask the less interesting onesEgor Tensin2021-01-18
|
* workflows: check if Travis/AppVeyor are brokenEgor Tensin2021-01-17
|
* GIANT CLUSTERFUCK OF A COMMITEgor Tensin2021-01-17
OK, this is epic. I was basically just trying to a) support Clang and b) add more test coverage. _THREE MONTHS_ and a few hundred CI runs later, this is what I came up with. I don't know how it ended up being what it is, but here we go. Some highlights of the changes: 1) CI builds has been moved to GitHub Actions, 2) the entire notion of a toolchain has been reworked; it now supports Clang on all platforms. * .github: this directory contains the GitHub Actions workflow scripts/actions. In the process, I created like 6 external GitHub actions, but it's still pretty massive. An upside is that it covers much more platform/toolchain combinations _and_ check a lot of the expected post-conditions. TODO: .ci/Makefile is obsolete now, as well as .travis.yml and .appveyor.yml. * common.cmake: added Clang support. In the process, a great deal has been learned about how CMake works; in particular, static runtime support has been reworked to be more robust. * project: the entire notion of a "toolchain" has been reworked. Instead of a measly --mingw parameter, there's now a separate --toolset parameter, which allows you to choose between GCC, Clang, MSVC, etc. Both Boost and CMake build scripts were enhanced greatly to support Clang and other toolchains in a more robust way.