Versioning improvements

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.

[TheElixZammuto]

Description

This PR adds an improved versioning system.

1. CMake has been modified to add support to https://github.com/nocnokneo/cmake-git-versioning-example, so it uses git describe to get the git tag, the current commit and if the commit tree is dirty.

2. The Sunshine version has been prepended to the stdout for troubleshooting.

3. In the index.html file of the Web UI, communication with the GitHub API has been added, for fetching the latest version and letting the user know if a new version is available. release users only get notices of releases, while nightly users get both release and the last successful CI in the Ci.yaml

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

Screenshot

Issues Fixed or Closed

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

Could you also move version.h.in to ./src, and rename to version.h.

I might be wrong, but I think if we put it in ./src we won't even need to configure this file in CMakeLists.txt like I set it up originally.

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

[TheElixZammuto]

Could you also move version.h.in to ./src, and rename to version.h.

I've moved the file but kept the suffix, since the file is an intermediate source file. version.h is generated by Cmake

Also, there's a small typo in line 8 of version.h.in, PROJECT_VER_PATCH.

Fixed

[TheElixZammuto]

It seems I've broke the build, fixing this

[TheElixZammuto]

Build should be fixed now!

[ReenigneArcher]

Great! Just a few indentations to fix now in CMakeLists.txt

[ReenigneArcher]

For making the tag sync with the current master (0.17), I've merged master into nightly (there are only some merge commits)

When I updated the branch, I did so with a re-base and it removed the merge commits. I didn't know that would happen, but now I have a question.

Is this going to work reliably when building nightly builds (or PR builds), as we don't typically merge master back into nightly?

[TheElixZammuto]

The PR uses git for tag handling (it uses the git describe --tags --dirty command), so I think that if you tag a commit that is not present on nightly, the tag is not applied. e.g. before my merges, the version of the nightly was a much older then 0.17.0. (iirc was 0.11.0 ?). For nightly this works correctly but of course the UI does show a much older version

[TheElixZammuto]

The PR has now been updated to use the version number inside the CMakeLists.txt.
Nightly and dirty versions of sunshine are still handled based on the latest commit and if the commit tree is dirty or not.

[ReenigneArcher]

@TheElixZammuto Todo:

• fix cmake lint errors
• ensure .git directory is not excluded in dockerignore file

[ReenigneArcher]

@TheElixZammuto I fixed a couple of things in the builds, but still getting a dirty git tree in the docker builds. Any idea? I suppose it's not copying the .git directory correctly, although I'm not sure why.