View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010623 | Taler | merchant backoffice SPA | public | 2025-11-17 19:11 | 2025-12-04 17:41 |
| Reporter | sebasjm | Assigned To | Florian Dold | ||
| Priority | high | Severity | minor | Reproducibility | have not tried |
| Status | feedback | Resolution | open | ||
| Product Version | 1.0 | ||||
| Target Version | 1.5 | ||||
| Summary | 0010623: replace the prebuilt SPA development release procedure | ||||
| Description | what we have: taler-typescript-core/ $ make backoffice-dev-prebuilt ... checkout a prebuilt/ in the worktree ... uses contrib/next-dev-version.sh to increment the version ... compile & test or die ... commit the version number on package.json that is going to end on prebuilt ... push changes on current branch ... copy `dist` folders into `prebuilt` worktree ... push changes on prebuilt branch taler-merchant/ (manually) ... go into contrib/wallet-core update to the latest commit on prebuilt branch ... update spa lock file ... push changes problems: - still some manual work - duplicated version tags (due to long lived branches) - backoffice version should follow merchant.git versioning number - if we publish a new version from master or release/1.1.x it should be unambiguous when updating merchant.git if we are taking the latest 1.2 dev prebuilt or the latest 1.1 dev prebuilt proposal: taler-typescript-core/ $ make backoffice-dev-prebuilt ... checkout a prebuilt/ in the worktree +- get version from package.json, check the latest dev prebuilt from tags // for example, if it gets "1.2.0" from package.json // search for tags starting with "backoffice-spa-1.2.0-dev.*" // if not found it can assume that this is -dev.1 ... compile & test or die ... commit the version number on package.json that is going to end on prebuilt // this commit will mark the source used to build the dev prebuilt ++ tag commit with backoffice-spa-v1.2.0-dev.(n+1) // this tag the source that is going to be use to construct the prebuilt ... push changes on master ... copy `dist` content into `prebuilt` worktree // in this case the content will go on "spa/backoffice/v1.2.0-dev.2" ... push changes on prebuilt branch taler-merchant/ $ ./contrib/update-latest-prebuilt-spa ++ get current version of the repo // mechant.git is right now 1.2.0 on master ... update submodule taler-typescript-core tags to the latest remote/prebuilt ++ list all versions starting with 1.2.0 on the artifact folder with -dev.N , order desc by N, take the highest // in this case it will search for "/backoffice-spa/1.2.0-dev.*" ... updates the spa lock file with latest dev // the tag is in the source code, but the folder is in prebuilt // the the folder is not present it should be rebuilt from source // and pushed again in the prebuilt branch ... commit and push changes on current branch note: - since we are talking about merchant the script has 'backoffice-spa' hardcoded (we will have one script per component) - prebuilt is always append, consumer repo of wallet-core prebuilt will always update with newest content. in case of rollback changing lock file should be enough ADDITIONAL CHANGE: Makefile.am is taking content from: dist_spapkgdata_DATA = \ wallet-core/backoffice/bof \ wallet-core/backoffice/index.css \ wallet-core/backoffice/index.css.map \ wallet-core/backoffice/index.html \ wallet-core/backoffice/index.js \ .... and it should take the content from dist_spapkgdata_DATA = \ wallet-core/backoffice/$VERSION/bof \ wallet-core/backoffice/$VERSION/index.css \ wallet-core/backoffice/$VERSION/index.css.map \ wallet-core/backoffice/$VERSION/index.html \ wallet-core/backoffice/$VERSION/index.js \ which corresponds to the bootstrap # Generate Makefile.am in contrib/ cd contrib rm -f Makefile.am find wallet-core/backoffice/ -type f | sort | awk '{print " " $1 " \\" }' > Makefile.am.ext # Remove extra '\' at the end of the file truncate -s -2 Makefile.am.ext cat Makefile.am.in Makefile.am.ext >> Makefile.am # Prevent accidental editing of the generated Makefile.am So this will need to be refactored in order to make it work. | ||||
| Tags | No tags attached. | ||||
|
|
I've updated DD43: https://docs.taler.net/design-documents/043-managing-prebuilt-artifacts.html Where I disagree with the bug description is the tagging: I don't think it's *necessary* to have a tag like "backoffice-spa-1.2.0-dev.*" on prebuilt. We *can* have this tag to better see where a prebuilt component was updated, but it is not required, since we can have a directory structure where each folder contains a prebuilt version (with multiple versions possible). See the DD for details. |
|
|
problems with the solutions - still some manual work ==> only run a script on the repo and it must work (1) to create a dev release (2) to update to the latest dev release of an artifact - duplicated version tags (due to long lived branches) ==> long live branch may have same version in the package.json, this is not a problem until we need to release and consumer repo should take this version without ambiguity (don't rely on git commit but version name) for that we introduce the `component + version` tag name to tag the source, but not the prebuilt and function as a lock (o other branch can release this artifact) - backoffice version should follow merchant.git versioning number ==> spa should follow the version of the consumer - if we publish a new version from master or release/1.1.x it should be unambiguous when updating merchant.git if we are taking the latest 1.2 dev prebuilt or the latest 1.1 dev prebuilt ==> already explained regarding sparse checkout to optimize disk or network, I think that's secondary to me if we can't solve the firsts one to make easier and reliable releases. This is a process i want to do anytime i fix an important issue and we want it deployed fast on test. So sure, being fast is important but i want to run only one command to publish, only one command to update, always the same command and should work regardless of branches (or fail with a clear message) |
|
|
> still some manual work I don't see what part of it can't be automated. > duplicated version tags (due to long lived branches) (1) We don't do long-lived branches but trunk-based developmend and (2) duplicated version tags can't happen since we always tag the source repo, git prevents duplicated tags > backoffice version should follow merchant.git versioning number Hard disagree. Makes it much harder to know which is the source version of the SPA. > if we publish a new version from master or release/1.1.x it should be unambiguous when updating merchant.git if we are taking the latest 1.2 dev prebuilt or the latest 1.1 dev prebuilt It is unambiguous, because we're always taking a prebuilt folder that corresponds to a tagged (with the version number!) commit in the release branch. |
|
|
> I don't see what part of it can't be automated. The current steps has manual works, off course it can be automated and the proposal is in the ticket description is what I need to be confirmed. Could you please check what needs to be changed based on your requirements? > (1) We don't do long-lived branches but trunk-based developmend and (2) duplicated version tags can't happen since we always tag the source repo, git prevents duplicated tags It won't happen after we implement this proposal. Now it's not automated and you may follow the right steps but other (like me) may not. Currently tagging and pushing the tags is manual. > Hard disagree. Makes it much harder to know which is the source version of the SPA. ACK I don't mind, it was a feedback from 0010626. I will change the proposal once more. I would like to take 0010711 and run 3 scripts 1) make backoffice-dev-prebuilt after my change is complete 2) ./contrib/update-latest-prebuilt-spa on merchant.git and it will take the recent published version 3) update-sancastle.sh And it should be invariant to any branch (either wallet-core.git or merchant.git) and hopefully fast enough to update during the QC (!!) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-11-17 19:11 | sebasjm | New Issue | |
| 2025-11-17 19:12 | sebasjm | Assigned To | => Florian Dold |
| 2025-11-17 19:12 | sebasjm | Status | new => feedback |
| 2025-11-17 19:13 | Florian Dold | Summary | replace the development release procedure => replace the prebuilt SPA development release procedure |
| 2025-11-17 20:09 | sebasjm | Description Updated | |
| 2025-11-17 20:13 | sebasjm | Description Updated | |
| 2025-11-17 20:18 | sebasjm | Description Updated | |
| 2025-11-17 21:25 | sebasjm | Description Updated | |
| 2025-11-18 15:28 | sebasjm | Relationship added | related to 0010626 |
| 2025-11-22 23:00 | Christian Grothoff | Product Version | => 1.0 |
| 2025-11-22 23:00 | Christian Grothoff | Target Version | => 1.5 |
| 2025-11-25 14:29 | sebasjm | Relationship added | related to 0010651 |
| 2025-11-25 14:30 | sebasjm | Priority | normal => high |
| 2025-11-27 09:11 | Florian Dold | Note Added: 0026640 | |
| 2025-11-27 09:11 | Florian Dold | Assigned To | Florian Dold => sebasjm |
| 2025-11-28 20:30 | sebasjm | Note Added: 0026672 | |
| 2025-11-28 20:32 | sebasjm | Description Updated | |
| 2025-11-28 21:55 | Florian Dold | Note Added: 0026673 | |
| 2025-12-04 17:28 | sebasjm | Relationship added | related to 0010711 |
| 2025-12-04 17:41 | sebasjm | Note Added: 0026737 | |
| 2025-12-04 17:41 | sebasjm | Assigned To | sebasjm => Florian Dold |
