Nightly builds
還沒有人認領這個 Issue。
評估
這個 Issue 還沒有評估資料。
描述
Premise: We would like to distribute builds of Processing with upcoming features for people to try out without those features necessarily being included in the latest builds of Processing.
One thing that was already suggested before is we could manage these features as a build step, so that they can be included into the main branch without being necessarily activated
My suggestion for feature control would be: we add a gradle.properties to the repo and add subsequently it to the .gitignore, this will provide a template for the file that then can be freely modified by anyone building the project from scratch. We can also create gradle.nightly.properties or something similarly named, that will enable features on the nightly builds but not in the main build. In this way you could activate the feature on a build system level by checking the property:
if(property("includeExamples") == "true"){
create("examples"){
java{
srcDirs("examples")
}
}
}
For feature control in the code we could grab all the Gradle properties defined starting with processing.feature and pass them through to the rest of the code. This would mean we could activate them with the following:
static private String ExampleFeatureActive = Boolean.parseBoolean(System.getProperty("processing.feature.example", "false"));
The nice thing is that the gradle.properties are also easily modifiable within the Github Actions:
name: Build with Gradle
run: ./gradlew publish
env:
MAVEN_CENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }}
MAVEN_CENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_PASSWORD }}
ORG_GRADLE_PROJECT_mavenCentralUsername: ${{ secrets.MAVEN_CENTRAL_USERNAME }}
ORG_GRADLE_PROJECT_mavenCentralPassword: ${{ secrets.MAVEN_CENTRAL_PASSWORD }}
ORG_GRADLE_PROJECT_signingInMemoryKey: ${{ secrets.SIGNING_IN_MEMORY_KEY }}
ORG_GRADLE_PROJECT_signingInMemoryKeyPassword: ${{ secrets.SIGNING_IN_MEMORY_KEY_PASSWORD }}
ORG_GRADLE_PROJECT_version: ${{ needs.version.outputs.version }}
ORG_GRADLE_PROJECT_group: ${{ vars.GRADLE_GROUP }}
One challenge that I see with nightly builds is keeping track of revision numbers and versioning.
Right now any time a new release of Processing is created, we manually set the revision number and version, the Github actions responsible for those expect that in the format processing-$revision-$version and this is parsed to set those variables into the gradle build system.
We could either start creating versions with a tag to it, e.g. processing-1501-4.10.1-nightly and just increase the build tag every time. But we would run out of revision tags rather soon and I suspect it might be hardcoded into multiple placed to be 4 digits.
Finally we would need to update the website to ignore build released with any arbitrary tags so that only major versions would be shown within the website.
Lets discuss!
@catilac @SableRaf @tychedelia
- 主要語言
- Java
- 星號
- 497
- 分支
- 183
- 平均合併
- 4 小時 39 分鐘
- 30 天內合併 PR
- 3
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
processing/processing4 的其他 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 64/100
processing/processing4#1554 · 1 則留言 ·
-
難度 2/5 1-3 小時 新手友好度 76/100
processing/processing4#1515 · 1 個 reaction ·
-
bug
難度 3/5 1-2 天 新手友好度 55/100
processing/processing4#1573 ·
-
startup error 未關閉
難度 4/5 3-5 天 新手友好度 25/100
processing/processing4#1569 · 7 則留言 ·
-
Binaries under bin directory lack executable permissions for the snap and .deb packages for Linux 未關閉bug
processing/processing4#1567 · 3 則留言 · 1 個 reaction · 已指派 1 人 ·
查看 processing/processing4 的全部 Issue
相似的 Issue
-
documentation
難度 2/5 1-3 小時 新手友好度 65/100
inu-appcenter/memorIN-backend#288 ·
-
難度 2/5 1-3 小時 新手友好度 65/100
-
frontend maui-pilot pilot-ask question
難度 2/5 1-3 小時 新手友好度 75/100
-
難度 2/5 1-3 小時 新手友好度 75/100
-
area/plugin
難度 2/5 1-3 小時 新手友好度 75/100
kestra-io/plugin-kestra#190 ·