|
Size: 2909
Comment: add information on github actions
|
← Revision 11 as of 2023-09-05 19:20:56 ⇥
Size: 3346
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. 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 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. Furthermore, there is a workflow to ensure the code quality. This workflow checks the style and clang-tidy tests. Our final workflow is only executed on pushes to the main branch of the {{{aibasel/downward}}} repository and updates the documentation. |
| 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]]. | |
| Line 13: | Line 13: |
| 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 15: |
| 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 CPLEX you have to acquire a license. |
| Line 26: | Line 17: |
| 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 of CPLEX. This is not be covered by the 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, CPLEX 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 a test for CPLEX, then you have to acquire a license (CPLEX provides a free academic license). The !GitHub Actions have to download the installer (for CPLEX). Thus, you have to upload it to a server of your choice and set its URL as a !GitHub secret. In your !GitHub repository go to `Settings->Secrets` and add a secret. !GitHub Actions state that they censor secrets in the console output. The following secrets can be defined: * CPLEX2211_LINUX_URL: Enables CPLEX 22.11 on the Ubuntu workflow * CPLEX2211_WINDOWS_URL: Enables CPLEX 22.11 on the Windows workflow 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. == 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, see "Tested software versions" at the [[https://github.com/aibasel/downward/|repository]]. |
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. 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 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. Furthermore, there is a workflow to ensure the code quality. This workflow checks the style and clang-tidy tests. Our final workflow is only executed on pushes to the main branch of the aibasel/downward repository and updates the documentation.
LP Solvers
![/!\](/moin_static1911/rightsidebar/img/alert.png "/!\"){kind=small}
For CPLEX you have to acquire a license.
Do not publish the installer of CPLEX. This is not be covered by the 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, CPLEX cannot be tested automatically on a fork (see issues issue970 and issue971). If you want to run a test for CPLEX, then you have to acquire a license (CPLEX provides a free academic license). The GitHub Actions have to download the installer (for CPLEX). Thus, you have to upload it to a server of your choice and set its URL as a GitHub secret. In your GitHub repository go to Settings->Secrets and add a secret. GitHub Actions state that they censor secrets in the console output. The following secrets can be defined:
- CPLEX2211_LINUX_URL: Enables CPLEX 22.11 on the Ubuntu workflow
- CPLEX2211_WINDOWS_URL: Enables CPLEX 22.11 on the Windows workflow
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.
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, see "Tested software versions" at the repository.