Remove ClientFiles from level1 repo

[warpech]

ClientFiles and PartialToStandaloneHtmlProvider are part of level1 repo.

When making changes to client files, it causes problems:

• conflicts and verbosity in CHANGELOG.md
• multiple branches needed for Starcounter 2.3.1 and 2.4
• it is difficult to override static files that come with Starcounter. For that we use SysUpgrade app, but we don't like to maintain it as a separate thing.

It's like to propose an alternative. Let's use SysUpgrade (renamed to Starcounter.ClientFiles) that is separately versioned and released as a NuGet package.

It would be versioned using semver, for example Starcounter.ClientFiles 1.x.y contains Polymer 1 and Starcounter.ClientFiles 2.x.y contains Polymer 2.

Level1 would pick Starcounter.ClientFiles from NuGet and take the class PartialToStandaloneHtmlProvider and the client files from the package.

Alternatively, client files can really be removed from Starcoutner and be provided by Starcounter.ClientFiles app. This is simple to do, but would break the "apps don't depend on each other" principle.

@ubbeK, @joozek78, @miyconst WDYT?

cc @Starcounter/webplatformteam

[miyconst]

GitHub should have a +100 emotion, +1 is just not enough for this issue.

[ubbeK]

All breaking out from Level1 is music to my ears.

[alshakero]

YES YES YES

[warpech]

I don't know how to do it, though. But I guess you know it better. I suggest to take the following steps:

• [ ] @alshakero please make sure that the master branch in SysUpgrade has the same static files as Starcounter 2.4
• [ ] @ubbeK please add a VS project in SysUpgrade (on a new branch) that contains the class Starcounter.PartialToStandaloneHtmlProvider and provide a dry-run instructions how to build Level1 with it.

Should we really use NuGet or rely on branches/tags in Git, just like with Simplified. How is it done in other repos in the Starcounter org that are included in Level1?

[ubbeK]

@ubbeK please add a VS project in SysUpgrade (on a new branch) that contains the class Starcounter.PartialToStandaloneHtmlProvider and provide a dry-run instructions how to build Level1 with it.

FYI, It will take at least one week before I can even start to dig a bit deeper with this.

[warpech]

Is there someone else who knows how to do it?

[ubbeK]

Probably, but everyone will probably say the same thing as I did.

My view of how it would be implemented is to create a local Nuget package which Level1 consumes in the CI chain. The solution for this has been discussed and there is a Minute about it.

But then, we would have to release it once in a while so a Level1 developer can work smoothly. A proper automatic framework/build environment is not in place for this.

[warpech]

Sounds great! I think we can wait a week, no problem. Thanks!

[ubbeK]

Sounds great! I think we can wait a week, no problem. Thanks!

Lets hope I get that far, it is really time to start with that functionality.

[warpech]

Correction to the OP: PartialToStandaloneHtmlProvider.cs can actually stay in Level1 repo as long as we implement https://github.com/Starcounter/Home/issues/334

[warpech]

SysUpgrade was renamed to StarcounterClientFiles

[warpech]

StarcounterClientFiles is ready for this change.

In level1 you can replace https://github.com/Starcounter/level1/tree/develop/src/BuildSystem/ClientFiles and replace it with dynamically loaded master branch of https://github.com/Starcounter/StarcounterClientFiles.

In TeamCity this branch name should be a parameter GIT_CLIENTFILES_BRANCH with the default value master.

Once we have a first tag (https://github.com/Starcounter/StarcounterClientFiles/issues/14), we will replace the default value master with 1.0.0 and then 2.0.0 and so on.

@ubbeK can you pls work on this? This will make our Monday release of Polymer 2.0 simpler (https://github.com/Starcounter/RebelsLounge/issues/188).

[ubbeK]

I was thinking that this would be solved through a nuget package, and tested through local nuget package directory/feed (state of that may be found here: https://github.com/Starcounter/AdminTrack/issues/390). Would that meet web platform teams needs?

[warpech]

Thanks for bumping it here, I missed the question in AdminTrack. My questions here: https://github.com/Starcounter/AdminTrack/issues/390#issuecomment-351973367

[ubbeK]

So why do we need to release these files in the installer? Purly for Administrator? Any other reasons?

[warpech]

For 2 reasons:

1. Starcounter version comes with a certain version of client files. So you know that Starcounter 2.4.0.4481 comes with StarcounterClientFiles 2.1.1 that includes Polymer 2.3.1 and Palindrom 3.1.0
2. for Administrator

[ubbeK]

So this will be done.

For Windows TC builds, Starcounter develop branch ONLY

• Sources from StarcounterClientFiles @ 2.x branch will be pulled, TC environment variable will be created which specifies what branch to use, 2.x by default
• ClientFiles from Level1 @ develop branch will completely be removed.
• A new step in the TC build script will be added to simply copy sys folder to the output directory for the installer (same place where the Level1 ClientFiles used to be placed by compiling Level1.sln):

  %StarcounterBin%/ClientFiles
  /StaticFiles
      /sys
          /<all web components>
  .bowerrc
  .gitignore
  bower.json
  bower-list.ext

Question: Are the bower and gitignore files really necessary? Isn't /sys folder enough?

@warpech Is this what is requested?

Note that we will implement a proper solution for the copy step in the future.

[warpech]

Question: Are the bower and gitignore files really necessary? Isn't /sys folder enough?

bower.json and bower-list.txt files are necessary because they are a reference to the versions used.

Only the files which name begins with a dot can be omitted, but they do no harm either.

---

This is what was requested, thank you! I have only one comment:

I need to track what version of StarcounterClientFiles was included in a Starcounter build, so that this information can be published in the release notes of Starcounter, etc. I can add this information to bower.json in StarcounterClientFiles. Is there a better idea for that?

[ubbeK]

I need to track what version of StarcounterClientFiles was included in a Starcounter build, so that this information can be published in the release notes of Starcounter, etc. I can add this information to bower.json in StarcounterClientFiles. Is there a better idea for that?

Well, we save each git commit hash per repository together with Starcounter version, see example: https://github.com/Starcounter/CI.BuildSystem/blob/develop-build-num/BuildNumberInfo.json, StarcounterClientFiles will also be added there (which I forgot to mention). Other than that, we dont have any automated solution.

[warpech]

Well, we save each git commit hash per repository together with Starcounter version, see example: Starcounter/CI.BuildSystem:BuildNumberInfo.json@develop-build-num

Wow, that's a revelation to me. I wasn't aware there's so much information about each build. This is perfect.

cc @Starcounter/webplatformteam

[ubbeK]

I just made an installer with the solution described above, would @warpech or @tomalec care to test it out?

https://teamcity.starcounter.org/viewLog.html?buildId=45675&buildTypeId=Starcounter_DevelopDailyWindows&tab=artifacts

[warpech]

I just tried it out. It works spotless!

[ubbeK]

This has now been merged. New installer should be uploaded to http://downloads.starcounter.com/download tonight.

[ubbeK]

Closing as fixed