Changes to repository URLs will break the build pipeline

[TrueMedHemmo]

If a project has changed reporitory url after the first install, npm run build-all may break for any subsequent install.

Currently happens due to the change from privatesky to opendsu repo urls.

Steps to repro:

• Get a fully older codebase of epi-workspace & dependencies
• npm install
• npm run build-all
• Update to latest codebase
• npm install
• npm run build-all

Workaround: Delete any folders causing problems eg. "backoffice-frontend" and run a new install

Permanent solution: Identify when version control reports back with this specific error and programmatically delete&reinstall.

[asaccool]

This behavior was meant to be a feature of the octopus. In case that a contributor did a fork of a repo and he was working of a different url octopus stops, shows the situation, allows the dev to save his work if needed with specific git commands, update the remote urls and after that the installation process can be re-run.

[asaccool]

Not always the installation process need to be run in case as an update of the workspace. During development, we recommend to do at least one fresh checkout of the workspace per day. In this way many potential situation can be quickly fixed. Eg main workspace structural changes, new env or config files etc.

[asaccool]

Webstorm IDE has update project feature that verify and updates all git repos that is much faster and can be used during dev process.

[asaccool]

@TrueMedHemmo taking all the information above, what do you think about this issue: we keep it opened or we can consider a feature like it was meant from the begging?

[TrueMedHemmo]

All this sounds reasonable from a local development standpoint. It does have to be documented though, otherwise on-boarding future developers might be troublesome. If it is already documented, that document should be shared to SSAPP devs.

Given that this is a feature, not a bug. How would this all track to an SSAPP production server deployment? How would a CI/CD pipeline, for example, manage these?

Currently SSAPP needs to stand on top of an active epi-workspace fork in order to run. So any changes to dependencies that could result in a mismatch will require an SSAPP developer to pull latest changes from epi-workspace to their own fork, solve any merge issues and then pull these changes to the production server.

This is what I had to do on last Thursday/Friday. Once I understood the cause, it was no biggie to solve, but the solution required significant human interaction. I had to manually remove 6 folders through trial and error: remove one folder, try build, remove another folder and then try build. This process took quite some time because each build on the server took a bit.

In an ideal world when this is in production this is how I foresee TrueMed SSAPP updates to be delivered:

1. TrueMed developer writes code and commits it to GitHub in a development branch
2. TrueMed lead developer approves code for release and merges it to staging branch
3. GitHub CI pipeline triggers a build event on the TrueMed SSAPP staging server
4. In TrueMed SSAPP staging server: EPI is updated to latest stable automatically
5. In TrueMed SSAPP staging server: SSAPP is updated to latest commit automatically
6. In TrueMed SSAPP staging server: npm run build-all is executed automatically
7. In TrueMed SSAPP staging server: automated unit testing is executed to verify functionality
8. GitHub CI pipeline reports back on the success of this job
9. TrueMed lead developer can use this data to make a judgement call whether to deploy to production
10. GitHub CI pipeline triggers a build event on the TrueMed SSAPP production server as seen in steps 4-8.

Running builds and installs is a must on the server itself given the nature of the current KeySSI management. The KeySSI must not change, so a CI/CD pipe can't build it on a temporarily spun up server and then deploy the resulting data to the production server, because the SSI would be different every time.

With all this in mind, there should be ways to ensure that simple issues can be resolved automatically without the need for manual intervention. Otherwise we're going to be burning hours on unnecessary steps that could very well be automated with future updates.

The sooner automation is possible, the more hours we can save.

If these steps can't be automated, I think it's safe to consider that we instead look for a way to deliver SSAPPs without the need of having an EPI client with a mountain of dependencies.

One obvious improvement would be to remove as many moving components as possible from the SSAPP foundation server project with only mission critical shared components in place. Eg. whatever happens during the KeySSI handshakes and responses back. Though that will still have everything running on an "unfamiliar" web client.

Ideally the SSAPP would be delivered without the need for Octopus and SSAPP developers can entirely manage their own pipeline with tools they are familiar with.

All of this could be made available through a single package (via npm preferably) that delivers that functionality to whatever project that needs it.

If there is no package like that yet, we would need documentation on exactly how the SSAPP and EPI communicate. Then it would be possible to build a package like this. Allowing the KeySSI to be signed and locked with a simple environment variable, which could be deployed to any required environment would be perfect.

So to conclude: If existing features prevent stable build automation, then we should look to make SSAPP delivery more lightweight.

Perfect solution would be to eliminate as much of the EPI cross-dependencies as possible from the SSAPPs. Ideally SSAPP providers do not even need to embed their app into a web server client that they do not know how to maintain (epi-workspace).

SSAPP devs should be able to build a web app with frameworks of their own preference and only utilize a lightweight SDK package to enable the required endpoints.