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
Copy file name to clipboardExpand all lines: ReadMe.md
+88-39Lines changed: 88 additions & 39 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,21 @@
1
+
# Good to know
2
+
3
+
A purpose is quick cicd.
4
+
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.
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.
11
+
12
+
(Dependabot should automatically merge none breaking update too)
13
+
14
+
Strict branch and commit naming is enforced for versioning, and versioning and changelog of the repo and packages are automated from them.
15
+
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.
1
18
2
-
## qqqq unlike in nuget feed git package feed doesnt display this file so to see it you need to look in the actual nuget package
3
19
# About
4
20
5
21
@@ -31,6 +47,8 @@ We also need a folder with an index.html end point for this.
31
47
32
48
Both these options work in this project.
33
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
+
34
52
## Details
35
53
36
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
@@ -47,9 +65,55 @@ in the pipeline?
47
65
Going into the pure wasm project or .client project and running a publish
48
66
dotnet publish --configuration Release
49
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
+
50
108
## Notes
51
109
Also DevServer needed adding to .client
52
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)
@@ -82,54 +150,35 @@ tr td:nth-child(2) {
82
150
# Project Structure
83
151
| Description | File Structure |
84
152
|----------------|-------------|
85
-
||┣ GitPageBlazorWASM |
86
-
| 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