You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can change your version of your package in the centralised solution and it will be picked up in consuming projects.
5
+
You can optionally use a project reference for faster development by setting a flag.
6
+
A build number could be automated into package names, the package already is automatically created on build.
7
+
So it should be possible to have a consuming project automatically get the version as a flag also for fast development across the package and consuming project.
2
8
9
+
The pipeline is similar pushing to your branch makes a package if tests are passed and updates the test page to show it. Merging does the same
10
+
but makes a production package and gh-page site.
3
11
12
+
(Dependabot should automatically merge none breaking update too)
4
13
5
-
# Local Development
6
-
- inc the version in local props
7
-
- save
8
-
- build package project (debug)
9
-
- build solution (debug)
10
-
- run
11
-
- for wasm use release and client
12
-
- for hosted wasm use host and debug
14
+
Strict branch and commit naming is enforced for versioning, and versioning and changelog of the repo and packages are automated from them.
13
15
14
-
## Trouble shooting
15
-
- clean restore solution and try again
16
-
- look in the sharedpages, look in depenency in solution explorer, open the package version drop down
17
-
- is the version what you expect?
18
-
- is there an error
19
-
- if it still doesnt work increment the version and use the process again
20
-
21
-
## Bonus
22
-
- there is probably a way to increment version with timestamps or build number to automate it more
23
-
24
-
## extras
25
-
- you can use a local feed two visual studio and see new components in LH for example
26
-
- LH could be setup to automatically update too, system environment variables may help or a txt file to read in csproj to sinc versions
16
+
Having testing, package build, github pages in the same solution is to enable quick development and automatic testing of packages before being built,
17
+
and automatic version and release of pages and packages.
27
18
28
19
# About
29
20
@@ -56,6 +47,8 @@ We also need a folder with an index.html end point for this.
56
47
57
48
Both these options work in this project.
58
49
50
+
On push the project make a package, hosts it, makes a testpage, on merging the branch to master it makes a production page and package.
51
+
59
52
## Details
60
53
61
54
The 404 page is because the Blazor is a spa the routing does not work as a github page, such that from the blazor entry point page you
@@ -72,9 +65,55 @@ in the pipeline?
72
65
Going into the pure wasm project or .client project and running a publish
73
66
dotnet publish --configuration Release
74
67
68
+
## What to look at
69
+
70
+
yml files, and csproj, and solution configurations, appsettings in client, the githubs themselves.
71
+
72
+
73
+
74
+
### YML files
75
+
76
+
It would be better if everywhere system environmental variables can be used that github environmental variables can be used.
77
+
Due to centralisation, and projects having different debug and release behavior and automatic package building these advantages coming together caused challenges.
78
+
In addition blazor client has its own challenges in receiving values. So sed is used a bit. Recommend for future just deleting and renaming files
79
+
for simplicity where the variables are safe.
80
+
81
+
Nektos Act has also been used with this project to run local pipelines as a test
82
+
83
+
The desired output would be environment value for whether gh_pages are being generated as a flag for how the client builds, a flag for whether to build the package,
84
+
and then building the whole solution. This may be worth exploring again if there are issues with lock files being out of sync for example. As the pipeline
85
+
builds projects not a whole solution build.
86
+
87
+
#### Dev
88
+
- multiple checks run, all of them run so that you can see if multiple fail but all must suceed to have package creating
89
+
- semver can fail if a change isnt required so has a an error catch "--dry run" may actaully be better first
90
+
- semver versions the repo, and it provides the version we will apply to the package
91
+
- the package also has a timestamp added so its always updated, this is not best practice however suits our purpose in development
92
+
- if there isnt a new version needed we can use the git tag version value, which isnt a recalculation using other commits so isnt as good but useful still
93
+
- in development packages have branch names in them (they cant be marked prerelease in the git package feed)
94
+
- the package is built
95
+
- the package is then used in a build of sharedpages, which is then used in the release client build which generates published files for gh-pages
96
+
- the published pages is put in an artifact
97
+
- a script in a separate repo so there can be a separate test page is run (there is a copy in this repo) it consumes the artifact and makes the page
98
+
99
+
#### Pull request
100
+
- just some checks they can be run even if they fail to see if there are multiple errors. They only show temporarily in the pr ui section of the
101
+
git pull request but can be seen in actions.
102
+
103
+
104
+
#### Release
105
+
- similar to dev but without tests as these have already happened and no feature name in package, and the gh-page is released on this repo.
106
+
107
+
75
108
## Notes
76
109
Also DevServer needed adding to .client
77
110
111
+
# Future Recommendation
112
+
113
+
There are options for making packing the blazor more efficient, as in smaller for the browser using it.
114
+
The would be worth exploring there are recommendations in the build tasks when the pipeline runs, also mudblazor is open and any process they have is
-[microsoft official docs (didn't actually use these but if end up needing to change it could start here)](https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-8.0#github-pages)
@@ -107,54 +150,35 @@ tr td:nth-child(2) {
107
150
# Project Structure
108
151
| Description | File Structure |
109
152
|----------------|-------------|
110
-
||┣ GitPageBlazorWASM |
111
-
| The github page is aimed at this and gets the version from gh-page branch. .Client publishes a standalone wasm site here |    ┣ docs |
| Because its a spa we need to redirect 404 back to our index page parse them to take users to pages on refresh or if they go there directly |            ┣ 404.html |
| just for making wiki style site if we decide to use the .client for testing and for creating the github page site then we dont need this |    ┣ GitPageBlazorWASMProgressive |
| Centralised package dependancy and config file for cicd |┣ GitPageBlazorWasm |
154
+
| Test host client, and if built with release standalone client |    ┣ GitPageBlazorWASM.Client |
155
+
| The package that will be consumed by LH for example |    ┣ Package.BlazorComponentLibrary |
156
+
| A seperate component rewriten in the pipeline with the package number |            ┣ BCLVersion |
| Bunit and E2E tests, the E2E none javascript tests require prerendering and hence the server wasm project for testing |    ┣ PlaywrightXUnitGoesHere |
| to keep the projects slim, and if we decide to have seperate programs for creating the sites we put the site in a seperate project that everything can use, this wouldnt be packaged |    ┣ SharedPages |
| we need this for prerendering this is the same kind of set up we would use when we consume our libraries (though see MVCBlazor project for actual setup) |    ┗ TestHostPrerenderWASM |
|the client is standalone on release and used by TestHostPrerenderWASM in debug for testing. Look for the release conditions to see how it does both|            ┗ TestHostPrerenderWASM.Client |
177
+
|Debug hosted by test host, standalone on release for gh-pages|            ┗ TestHostPrerenderWASM.Client |
|if we put these in wwwroot then when running debug we would have two entry points so we keep them here and copy them on publish|                    ┣ GitPagesEntryPoint |
|Files copied to wwwroot on release to enable to standalone|                    ┣ GitPagesEntryPoint |
181
+
|Blazor is a spa and we are hosted by github so it is necassary to redirect 404s for routing|                            ┣ 404.html |
0 commit comments