|
Size: 2909
Comment: add information on github actions
|
Size: 3832
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 3: | Line 3: |
| = Github Actions = | = GitHub Actions = |
| Line 5: | Line 5: |
| Github actions is the continuous integration tool of Github. Actions are setup using so-called workflows, where each workflow possibly consists of different jobs. Actions can be triggered by events on the repository such as pushes, pull request and others. | GitHub Actions is the continuous integration tool of GitHub. Actions are setup using so-called workflows, where each workflow possibly consists of different jobs. Actions can be triggered by events on the repository such as pushes, pull request and others. Any file found in {{{REPOSITORY/.github/workflows}}} which ends on {{{.yml}}} automatically defines a workflow. If you want to enable or disable GitHub Actions, change your repository settings on GitHub via `Settings->Actions`. |
| Line 7: | Line 7: |
| We currently have implemented some basic Github actions which run a subset of the tests that the [[ForDevelopers/Buildbot|buildbot]], our current continuous integration tool, runs. All of them are triggered by pushing commits to the main repository and by pushing to pull requests opened against the main repository. | Currently, we have implemented some basic GitHub Actions which run a subset of the tests that the [[ForDevelopers/BuildBot|buildbot]], our current continuous integration tool, runs. All of them are triggered by pushing commits to the main repository and by pushing to pull requests opened against the main repository. |
| Line 9: | Line 9: |
| There are two workflows which run on the "latest version" of Windows and MacOS (as provided by Github through Docker images). Here, we use the default compilers shipped with these OS versions and only run the translator and standard config tests, i.e., we run `tox -e translator,search`. | The first workflow runs on MacOS and uses the default compilers. It executes the driver, translator, and the standard config tests, i.e. it runs `tox -e driver,translator,search`. Another workflow runs on multiple Windows versions and Visual Studio Enterprise versions. This workflow runs the translator and search tests (once the current version of VAL accepts the plans of Fast Downward, we want to add the driver tests). There is a workflow for Ubuntu that runs different combinations of different versions of Ubuntu, Python and compilers. On this workflow we execute the driver, translator, and search tests. Finally, there is a workflow to ensure the code quality. This workflow checks the style and clang-tidy tests. |
| Line 11: | Line 12: |
| There is a workflow for Ubuntu that runs different combinations of different versions of Ubuntu, Python and compilers. The current idea is to run the actions on the two latest LTS releases of Ubuntu. On the older one, we use the default versions of GCC and CLANG. On the newer one, we additionally use the newest versions of GCC and CLANG available. On the older one, we use Python 3.6 (the current minimal version required), on the newer one, additionally Python 3.8 (the most recent version compatible). These versions should be adapted once we decided on rules on how to determine and update the requirements more generally, see [[http://issues.fast-downward.org/issue1003|issue1003]]. | We also want to discuss if we want to replace our the buildbot by GitHub actions eventually: [[http://issues.fast-downward.org/issue1001|issue1001]] |
| Line 13: | Line 14: |
| On both Ubuntu versions, we compile with CPLEX and SOPLEX if the Github actions "secret" (the URL from where the installers can be retrieved) is setup. See issues [[http://issues.fast-downward.org/issue970|issue970]] and [[http://issues.fast-downward.org/issue971|issue971]] on licensing. For the main repository, secrets are set up, which means that commits on the main repo always trigger builds with LP solvers. For commits pushed to pull requests, the secrets need to be set up on the fork the pull request was opened from. If they are not set up, the builds will not use LP solvers. If you want to set up secrets, contact Silvan. | == LP Solvers == |
| Line 15: | Line 16: |
| The following lists the current combinations of versions we test. We only run the tests on the default GCC version and not with all compilers. * compile (ubuntu-18.04, gcc, 3.6) * compile (ubuntu-18.04, clang, 3.6) * compile (ubuntu-20.04, gcc, 3.6) * compile (ubuntu-20.04, gcc-10, 3.6) * compile (ubuntu-20.04, clang, 3.6) * compile (ubuntu-20.04, clang-11, 3.6) * test (ubuntu-18.04, gcc, 3.6) * test (ubuntu-20.04, gcc, 3.6) * test (ubuntu-20.04, gcc, 3.8) |
/!\ For some LP solvers you have to acquire a license. |
| Line 26: | Line 18: |
| We also want to discuss if we want to replace our the buildbot by Github actions eventually: [[http://issues.fast-downward.org/issue1001|issue1001]] | /!\ Do not publish the installer/source code of an LP solver. This might not be covered by your license. On both Ubuntu versions, we compile and test with CPLEX and SOPLEX. On both Windows versions, we compile and test with CPLEX. Due to licensing, the LP solvers cannot be tested automatically on a fork (see issues [[http://issues.fast-downward.org/issue970|issue970]] and [[http://issues.fast-downward.org/issue971|issue971]]). If you want to run an LP solvers, then you have to acquire a license (CPLEX and SoPlex provide academic licenses). The GitHub Actions have to download the source code (for SoPlex) and the installer (for CPLEX). Thus, you have to uploaded those to a server of your choice. In your GitHub repository go to `Settings->Secrets`. Add for every LP solver you want to use their secret. The value of a secret is the URL from where the LP solver can be downloaded. GitHub Actions state that they censor secrets in the console output. The following secrets can be defined: * CPLEX129_LINUX_URL: Enables CPLEX 12.9 on the Ubuntu workflow * CPLEX129_WINDOWS_URL: Enables CPLEX 12.9 on the Windows workflow * SOPLEX311_URL: Enables SoPlex 3.1.1 on the Ubuntu workflow /!\ You have to define both, CPLEX129_LINUX_URL and SOPLEX311_URL, for the Ubuntu workflow to test the LP solvers. For the main repository, the secrets are set up, which means that commits on the main repo always trigger builds with LP solvers. For commits pushed to pull requests, the secrets need to be set up on the fork the pull request was opened from. If they are not set up, the builds will not use LP solvers. If you need help with the secrets, contact Silvan or Patrick. == Tested Versions == [[../Requirements|Requirements]] defines the policy for the version we want test, but keep in mind that we cannot be up to date with every version release. For the currently tested versions, consult the [[https://github.com/aibasel/downward/tree/main/.github/workflows|workflow files]]. |
Back to developer page.
GitHub Actions
GitHub Actions is the continuous integration tool of GitHub. Actions are setup using so-called workflows, where each workflow possibly consists of different jobs. Actions can be triggered by events on the repository such as pushes, pull request and others. Any file found in REPOSITORY/.github/workflows which ends on .yml automatically defines a workflow. If you want to enable or disable GitHub Actions, change your repository settings on GitHub via Settings->Actions.
Currently, we have implemented some basic GitHub Actions which run a subset of the tests that the buildbot, our current continuous integration tool, runs. All of them are triggered by pushing commits to the main repository and by pushing to pull requests opened against the main repository.
The first workflow runs on MacOS and uses the default compilers. It executes the driver, translator, and the standard config tests, i.e. it runs tox -e driver,translator,search. Another workflow runs on multiple Windows versions and Visual Studio Enterprise versions. This workflow runs the translator and search tests (once the current version of VAL accepts the plans of Fast Downward, we want to add the driver tests). There is a workflow for Ubuntu that runs different combinations of different versions of Ubuntu, Python and compilers. On this workflow we execute the driver, translator, and search tests. Finally, there is a workflow to ensure the code quality. This workflow checks the style and clang-tidy tests.
We also want to discuss if we want to replace our the buildbot by GitHub actions eventually: issue1001
LP Solvers
![/!\](/moin_static1911/rightsidebar/img/alert.png "/!\"){kind=small}
For some LP solvers you have to acquire a license.
Do not publish the installer/source code of an LP solver. This might not be covered by your license.
On both Ubuntu versions, we compile and test with CPLEX and SOPLEX. On both Windows versions, we compile and test with CPLEX. Due to licensing, the LP solvers cannot be tested automatically on a fork (see issues issue970 and issue971). If you want to run an LP solvers, then you have to acquire a license (CPLEX and SoPlex provide academic licenses). The GitHub Actions have to download the source code (for SoPlex) and the installer (for CPLEX). Thus, you have to uploaded those to a server of your choice. In your GitHub repository go to Settings->Secrets. Add for every LP solver you want to use their secret. The value of a secret is the URL from where the LP solver can be downloaded. GitHub Actions state that they censor secrets in the console output. The following secrets can be defined:
- CPLEX129_LINUX_URL: Enables CPLEX 12.9 on the Ubuntu workflow
- CPLEX129_WINDOWS_URL: Enables CPLEX 12.9 on the Windows workflow
SOPLEX311_URL: Enables SoPlex 3.1.1 on the Ubuntu workflow
You have to define both, CPLEX129_LINUX_URL and SOPLEX311_URL, for the Ubuntu workflow to test the LP solvers.
For the main repository, the secrets are set up, which means that commits on the main repo always trigger builds with LP solvers. For commits pushed to pull requests, the secrets need to be set up on the fork the pull request was opened from. If they are not set up, the builds will not use LP solvers. If you need help with the secrets, contact Silvan or Patrick.
Tested Versions
Requirements defines the policy for the version we want test, but keep in mind that we cannot be up to date with every version release. For the currently tested versions, consult the workflow files.