studio/blender-studio-tools
13
32
Fork 19
Code Issues 22 Pull Requests 4 Projects Releases 1 Activity

Release System: Auto Update 'Addon Table' URLs & Upload Addon Zips #123

Closed
Nick Alberelli wants to merge 3 commits from (deleted):feature/release-system-atuo-update-table into main
pull from: (deleted):feature/release-system-atuo-update-table
merge into: studio:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 4 Commits 3 Files Changed 32 +90 -10
Nick Alberelli commented 2023-07-13 16:35:18 +02:00
Member
Copy Link

What's Changed:

  • Update Addon readme table during Release
  • Standardize Readme Table Version Numbers

TODO

  • Commit DST files to repo
  • Remove the above folder from git ignore
  • Mark this folder as gitLFS
  • Remove old archives from gitLFS
## What's Changed: - Update Addon readme table during Release - Standardize Readme Table Version Numbers # TODO - [x] Commit DST files to repo - [x] Remove the above folder from git ignore - [x] Mark this folder as gitLFS - [x] Remove old archives from gitLFS
Nick Alberelli changed title from WIP: Release System: Automatically Update Table Version Numbe to WIP: Release System: Automatically Update Table Version Number 2023-07-13 16:58:27 +02:00
Nick Alberelli force-pushed feature/release-system-atuo-update-table from 1451289421 to e656198556 2023-07-13 20:33:03 +02:00 Compare
Nick Alberelli commented 2023-07-13 20:40:17 +02:00
Author
Member
Copy Link

@fsiddi per your instructions I have committed the DIST folder to the repo in this branch.

The intention is that all the zips from the dist folder will automatically be pushed to https://studio.blender.org/pipeline/addons/overview to make them available for download.

This PR automatically updates the version numbers in the tables URLs and uploads the Zips (marked as LFS) to the repo. I just wanted to confirm that this is the correct method for submitting the zips before I merged it.

@fsiddi per your instructions I have committed the DIST folder to the repo in this branch. The intention is that all the zips from the dist folder will automatically be pushed to https://studio.blender.org/pipeline/addons/overview to make them available for download. This PR automatically updates the version numbers in the tables URLs and uploads the Zips (marked as LFS) to the repo. I just wanted to confirm that this is the correct method for submitting the zips before I merged it.
Nick Alberelli changed title from WIP: Release System: Automatically Update Table Version Number to Release System: Automatically Update Table Version Number 2023-07-13 20:40:20 +02:00
Nick Alberelli changed title from Release System: Automatically Update Table Version Number to Release System: Automatically Update Table Version Number & Upload Addon Zips 2023-07-13 20:40:40 +02:00
Nick Alberelli changed title from Release System: Automatically Update Table Version Number & Upload Addon Zips to Release System: Auto Update 'Addon Table' URLs & Upload Addon Zips 2023-07-13 20:41:07 +02:00
Nick Alberelli force-pushed feature/release-system-atuo-update-table from 34a72c3683 to 30bfc6225f 2023-07-13 22:08:39 +02:00 Compare
Nick Alberelli commented 2023-07-14 19:56:48 +02:00
Author
Member
Copy Link

Hello @fsiddi I had a conference with @ZedDB about this topic. He and I are not a fans of uploading the zips directly to the repo, and after creating this PR I can see that this DIST folder will rapidly expand in size with each new release.

If the purpose of uploading ZIPS to the git repo is to eventually copy it to the web server, this can be seen as redundant; users would be cloning down the DIST folder that they don't need, because they can generate these files themselves with the packaging script.

In light of these concerns we are providing two alternative solutions.

Possible Solutions

1: The Script that Copies the Repo Should also Package the Add-ons

The script that is currently used to push Doc changes to https://studio.blender.org/pipeline/ (which I call repo->webserver script)should also handle the creation and uploading of zip folder.

The process of releasing would be

  1. Run the release script on myside
  2. Create commits and changelogs indicating the version bump and push that to the repo
  3. The repo->webserver script would find these version bump commits and create zips for each addon and upload them to the webserver.

Advantages

  • Shortest path from our current situation to solving this issue

Disadvantages

  • Requires more involvment/work from @fsiddi
  • @TinyNick doesn't have full control over the addon release system
  • We will need to update the addon table URLs to exactly match what the repo->webserver script is packaging. So these two pieces of code depend on eachother

2: Use the Releases Page on Gitea

I know there is some reluctance to integrate further into Gitea, but this does seem like a more logical solution... in my opinion

In this senario each time the add-on release script is run we will create a "mono tag" that will indicate pipeline release. So currently we are on pipeline version 0.0.1. Each Pipeline release would contain all the addon zips with their own version numbers. The Release page would host the zips we intend to be downloaded from the addons table.

For example I created a test release here: https://projects.blender.org/TinyNick/blender-studio-tools/releases/tag/0.0.1

Advantages

  • The URLs for each zip would be known when I am running my release script
  • This means I can control the entire release system from my side, without changing the repo->webserver script.
  • This would host a history of previous addon versions for rolling back to.

Disadvanatages

  • The entire pipline tag needs to be bumped everytime an addon is updated
  • Further inegration with Gitea

Please let me know your opinion on this. My preference is solution 2.

Hello @fsiddi I had a conference with @ZedDB about this topic. He and I are not a fans of uploading the zips directly to the repo, and after creating this PR I can see that this DIST folder will rapidly expand in size with each new release. If the purpose of uploading ZIPS to the git repo is to eventually copy it to the web server, this can be seen as redundant; users would be cloning down the DIST folder that they don't need, because they can generate these files themselves with the packaging script. In light of these concerns we are providing two alternative solutions. # Possible Solutions ## 1: The Script that Copies the Repo Should also Package the Add-ons The script that is currently used to push Doc changes to https://studio.blender.org/pipeline/ (which I call `repo->webserver script`)should also handle the creation and uploading of zip folder. **The process of releasing would be** 1. Run the release script on myside 2. Create commits and changelogs indicating the version bump and push that to the repo 3. The `repo->webserver script` would find these version bump commits and create zips for each addon and upload them to the webserver. #### Advantages * Shortest path from our current situation to solving this issue #### Disadvantages * Requires more involvment/work from @fsiddi * @TinyNick doesn't have full control over the addon release system * We will need to update the addon table URLs to exactly match what the `repo->webserver script` is packaging. So these two pieces of code depend on eachother ## 2: Use the Releases Page on Gitea *I know there is some reluctance to integrate further into Gitea, but this does seem like a more logical solution... in my opinion* In this senario each time the add-on release script is run we will create a "mono tag" that will indicate pipeline release. So currently we are on pipeline version 0.0.1. Each Pipeline release would contain all the addon zips with their own version numbers. The Release page would host the zips we intend to be downloaded from the addons table. For example I created a test release here: https://projects.blender.org/TinyNick/blender-studio-tools/releases/tag/0.0.1 #### Advantages * The URLs for each zip would be known when I am running my release script * This means I can control the entire release system from my side, without changing the `repo->webserver script`. * This would host a history of previous addon versions for rolling back to. #### Disadvanatages * The entire pipline tag needs to be bumped everytime an addon is updated * Further inegration with Gitea Please let me know your opinion on this. My preference is solution 2.
Nick Alberelli force-pushed feature/release-system-atuo-update-table from 30bfc6225f to 2d2399660b 2023-07-14 20:24:43 +02:00 Compare
Francesco Siddi commented 2023-07-27 23:29:18 +02:00
Owner
Copy Link

We discussed IRL and agree to use the release pages. Interaction with Gitea should happen through the web API, using the requests library in the simplest way possible. The API will require a token, which can be stored in the .env file.

We discussed IRL and agree to use the release pages. Interaction with Gitea should happen through the web API, using the `requests` library in the simplest way possible. The API will require a token, which can be stored in the `.env` file.
Nick Alberelli commented 2023-08-02 10:18:15 +02:00
Author
Member
Copy Link

Moving the changes outlines in this pull request into studio/blender-studio-pipeline#134

Moving the changes outlines in this pull request into https://projects.blender.org/studio/blender-studio-pipeline/pulls/134
Nick Alberelli closed this pull request 2023-08-02 10:18:15 +02:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Kind
Breaking
Breaking change that won't be backward compatible

  
Kind
Bug
Something is not working

  
Kind: Community

Issues opened by members of the community / outside the studio

  
Kind
Documentation
Documentation changes

  
Kind
Easy
Simple to complete

  
Kind
Enhancement
Improve existing functionality

  
Kind
Feature
New functionality

  
Kind
Proposal
A proposal or idea that requires feedback

  
Kind
Security
This is security issue

  
Kind
Studio Request
Requested by a user at the Blender-Studio

  
Kind
Testing
Issue or pull request related to testing

  
Priority
Critical
The priority is critical

  
Priority
High
The priority is high

  
Priority
Low
The priority is low

  
Priority
Medium
The priority is medium

  
Reviewed
Confirmed
Issue has been confirmed

  
Reviewed
Duplicate
This issue or pull request already exists

  
Reviewed
Invalid
Invalid issue

  
Reviewed
Won't Fix
This issue won't be fixed

  
Status
Abandoned
Somebody has started to work on this but abandoned work

  
Status
Blocked
Something is blocking this issue or pull request

  
Status
Need More Info
Feedback is required to reproduce issue or to continue work

No Label
Kind
Breaking
Kind
Bug
Kind: Community
Kind
Documentation
Kind
Easy
Kind
Enhancement
Kind
Feature
Kind
Proposal
Kind
Security
Kind
Studio Request
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: studio/blender-studio-tools#123
No description provided.
Delete Branch "(deleted):feature/release-system-atuo-update-table"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?