Archives/OpenTTD-patches
2
0
Fork 0
mirror of https://github.com/JGRennison/OpenTTD-patches.git synced 2024-11-11 13:10:45 +00:00
Code Issues Packages Projects Releases Wiki Activity
f57296a033
OpenTTD-patches/.github/workflows/release.yml

133 lines
2.9 KiB
YAML
Raw Normal View History

Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
name: Release
on:
workflow_dispatch:
inputs:
ref:
description: 'Ref to build (for Pull Requests, use refs/pull/NNN/head)'
required: true
repository_dispatch:
# client_payload should be the same as the inputs for workflow_dispatch.
types:
- Build*
release:
types:
- published
jobs:
source:
name: Source
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-source.yml
secrets: inherit
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
docs:
name: Docs
needs: source
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-docs.yml
secrets: inherit
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
with:
version: ${{ needs.source.outputs.version }}
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
linux:
Feature: [Actions / CMake] support for generic linux builds (#8641) These bundles can be opened on any "modern" Linux machine with a driver that SDL2 supports. Machines needs at least glibc 2.15, which was released 10 years ago. It is build with CentOS 7 as base, and only assumes the following libraries are available on the system: - libc - libdl - libgcc_s - libpthread - librt - libstdc++ All other libraries the game depends on are bundled together with the game, so users don't need any library installed to use this bundle. The downside of course is that this increases the binary size a bit: 30 MiB of libraries are in this bundle. RPATH is used to make ld-linux find the folder libraries are stored in; however, system libraries are always used before these, in the assumption libraries on the user system are more up-to-date. Using -DOPTION_PACKAGE_DEPENDENCIES=ON switches on packaging of libraries in the "lib" folder. This requires CMake 3.16 to be installed; otherwise it will fail.
2021-02-05 11:31:27 +00:00
name: Linux (Generic)
needs: source
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-linux.yml
secrets: inherit
Feature: [Actions / CMake] support for generic linux builds (#8641) These bundles can be opened on any "modern" Linux machine with a driver that SDL2 supports. Machines needs at least glibc 2.15, which was released 10 years ago. It is build with CentOS 7 as base, and only assumes the following libraries are available on the system: - libc - libdl - libgcc_s - libpthread - librt - libstdc++ All other libraries the game depends on are bundled together with the game, so users don't need any library installed to use this bundle. The downside of course is that this increases the binary size a bit: 30 MiB of libraries are in this bundle. RPATH is used to make ld-linux find the folder libraries are stored in; however, system libraries are always used before these, in the assumption libraries on the user system are more up-to-date. Using -DOPTION_PACKAGE_DEPENDENCIES=ON switches on packaging of libraries in the "lib" folder. This requires CMake 3.16 to be installed; otherwise it will fail.
2021-02-05 11:31:27 +00:00
Feature: opt-in survey when exiting a game On first start-up, the game will ask if you want to participate in our automated survey. You have to opt-in, and can easily opt-out (via the Options) at any time. When opt-in, whenever you exit a game, a JSON blob will be send to the survey server hosted by OpenTTD. This JSON blob contains information that gives a global picture of the game just played: - What settings were used - How many humans vs AIs - How long the game has been played - Basic information about the OS / CPU All this information is kept very generic, so there is no chance we send private information to our survey server. Nothing in the JSON blob could identify you as a person; it mostly tells about the game played. At any time you can see what the JSON blob includes, by pressing the "Preview Survey Results" button in-game.
2023-04-25 17:43:45 +00:00
with:
survey_key: ${{ needs.source.outputs.survey_key }}
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
macos:
name: MacOS
needs: source
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-macos.yml
secrets: inherit
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
Feature: opt-in survey when exiting a game On first start-up, the game will ask if you want to participate in our automated survey. You have to opt-in, and can easily opt-out (via the Options) at any time. When opt-in, whenever you exit a game, a JSON blob will be send to the survey server hosted by OpenTTD. This JSON blob contains information that gives a global picture of the game just played: - What settings were used - How many humans vs AIs - How long the game has been played - Basic information about the OS / CPU All this information is kept very generic, so there is no chance we send private information to our survey server. Nothing in the JSON blob could identify you as a person; it mostly tells about the game played. At any time you can see what the JSON blob includes, by pressing the "Preview Survey Results" button in-game.
2023-04-25 17:43:45 +00:00
with:
survey_key: ${{ needs.source.outputs.survey_key }}
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
windows:
name: Windows
needs: source
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-windows.yml
secrets: inherit
Change: [Actions] stop using 'run-cmake' action for Release
2021-02-21 13:40:26 +00:00
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
with:
is_tag: ${{ needs.source.outputs.is_tag }}
Feature: opt-in survey when exiting a game On first start-up, the game will ask if you want to participate in our automated survey. You have to opt-in, and can easily opt-out (via the Options) at any time. When opt-in, whenever you exit a game, a JSON blob will be send to the survey server hosted by OpenTTD. This JSON blob contains information that gives a global picture of the game just played: - What settings were used - How many humans vs AIs - How long the game has been played - Basic information about the OS / CPU All this information is kept very generic, so there is no chance we send private information to our survey server. Nothing in the JSON blob could identify you as a person; it mostly tells about the game played. At any time you can see what the JSON blob includes, by pressing the "Preview Survey Results" button in-game.
2023-04-25 17:43:45 +00:00
survey_key: ${{ needs.source.outputs.survey_key }}
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
windows-store:
Feature: [Actions] Package builds for the Windows Store automatically
2021-02-04 22:09:38 +00:00
name: Windows Store
needs:
- source
- windows
if: needs.source.outputs.is_tag == 'true'
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/release-windows-store.yml
secrets: inherit
Feature: [Actions] Package builds for the Windows Store automatically
2021-02-04 22:09:38 +00:00
Change: [Actions] release Windows Store files to CDN Currently they had a name that the rest of our system cannot deal with correctly. "cert.pfx" is also not very descriptive from a system as a whole. As such, we now name it like any other file, so it can be published safely to the CDN.
2023-01-28 13:13:21 +00:00
with:
version: ${{ needs.source.outputs.version }}
Change: [CI] upload releases to new CDN (#11093)
2023-07-01 12:30:57 +00:00
upload-cdn:
name: Upload (CDN)
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
needs:
- source
- docs
- linux
- macos
- windows
Change: [Actions] release Windows Store files to CDN Currently they had a name that the rest of our system cannot deal with correctly. "cert.pfx" is also not very descriptive from a system as a whole. As such, we now name it like any other file, so it can be published safely to the CDN.
2023-01-28 13:13:21 +00:00
- windows-store
# As windows-store is condition, we need to check ourselves if we need to run.
# The always() makes sure the rest is always evaluated.
if: always() && needs.source.result == 'success' && needs.docs.result == 'success' && needs.linux.result == 'success' && needs.macos.result == 'success' && needs.windows.result == 'success' && (needs.windows-store.result == 'success' || needs.windows-store.result == 'skipped')
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
Change: [CI] upload releases to new CDN (#11093)
2023-07-01 12:30:57 +00:00
uses: ./.github/workflows/upload-cdn.yml
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
secrets: inherit
Add: [Actions] release workflow for both releases and nightlies This has several ways of being triggered: - When creating a new release via the GitHub interface. Fully automated that will produce new binaries, upload them, and it will even update the website to tell about the new version. - When triggered in an automated way from OpenTTD/workflows to start a nightly. - Manually via the Release workflow, which accepts branches, Pull Requests and tags to build. Rerunning a job is safe and should be without issues. Everything retriggers and updates what-ever might have been broken. In fact, except for dates, it should produce identical results. Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
2020-12-12 15:32:05 +00:00
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
with:
version: ${{ needs.source.outputs.version }}
folder: ${{ needs.source.outputs.folder }}
trigger_type: ${{ needs.source.outputs.trigger_type }}
Add: [Actions] Automatically upload releases to Steam (#8644)
2021-02-05 19:58:15 +00:00
upload-steam:
name: Upload (Steam)
needs:
- source
- linux
- macos
- windows
if: needs.source.outputs.trigger_type == 'new-master' || needs.source.outputs.trigger_type == 'new-tag'
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
uses: ./.github/workflows/upload-steam.yml
secrets: inherit
Add: [Actions] Automatically upload releases to Steam (#8644)
2021-02-05 19:58:15 +00:00
Change: [Actions] split GitHub workflows into several smaller ones
2023-01-28 12:32:30 +00:00
with:
version: ${{ needs.source.outputs.version }}
trigger_type: ${{ needs.source.outputs.trigger_type }}
Add: [Actions] upload releases to GOG automatically
2023-01-28 15:00:52 +00:00
upload-gog:
name: Upload (GOG)
needs:
- source
- linux
- macos
- windows
if: needs.source.outputs.trigger_type == 'new-tag'
uses: ./.github/workflows/upload-gog.yml
secrets: inherit
with:
version: ${{ needs.source.outputs.version }}
Reference in New Issue Copy Permalink