Deploy website

[mpranj]

Basics

These points need to be fulfilled for every PR:

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which
  contains _(my name)_)
  Please always add something to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy.
• The PR is rebased with current master.

If you have any troubles fulfilling these criteria, please write
about the trouble as comment in the PR. We will help you.
But we cannot accept PRs that do not fulfill the basics.

Checklist

Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar none of these points below
need to be checked.

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in THIRD-PARTY-LICENSES

Review

Reviewers will usually check the following:

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

If you are already Elektra developer:

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if the basics are fulfilled and you also
  say that everything is ready to be merged.

[markus2330]

Thank you for working on this! Note that the deployment is only done on a7.

To deploy on www.libelektra.org we would need to copy the artifacts there.

[mpranj]

I noticed that. I'd still like to somewhat automate it.

I was able to build it locally after all by checking the website Docker image. You really need to do the kdb global-mount && kdb mount-website-* [...] stuff, then it works.

Edit: so basically I don't know why/when it stopped working. 😄

[mpranj]

@markus2330 side note: www.libelektra on port 80 and 443 serve two completely different directories. I'll probably clean that up too if there was no reason to do that. To me this just complicates deployment.

[markus2330]

I noticed that. I'd still like to somewhat automate it.

It should not be too difficult to copy the artifacts to the right place (except of the login but this should already be fixed as we already copy docu&coverage reports to the community node). Additionally, we could also deploy the docker container on a VM on our server. @Mistreated is currently trying to get a VM running (as build agent). We could create one more VM for our docker deployments. But actually this was @Mistreated's task.

You really need to do the kdb global-mount && kdb mount-website-* [...] stuff, then it works.

Good to know. I wonder why this got broken on my system (I definitely did it at some point). The error message could definitely be improved, though 😄

[mpranj]

jenkins build libelektra please

[mpranj]

jenkins build libelektra please

[mpranj]

@markus2330 did I understand it correctly that we will get rid of website-backend completely, since it has not been working for a while?

When updating the images I noticed that using a newer gcc libasan requires privileged capabilities (ptrace) for the container during docker build. Firstly it seems that this is currently not even possible (upstream limitation). Second, I would not want to add any privileged capabilities to our deployed website-backend.

Do we:

1. get rid of website-backend completely
2. ignore and not update website-backend
3. update website-backend and add privileged capabilites (SYS_PTRACE) to the deployed backend
4. any other suggestions?

[sanssecours]

any other suggestions?

If think disabling AddressSanitizer (ASAN=OFF) for the website-backend might also fix the problem.

[mpranj]

(ASAN=OFF) for the website-backend

Thank you, I overlooked that option! I also thought it was not necessary, but @markus2330 suggested that this is for security reasons as it catches undefined behavior. The backend to my knowledge converts the configuration snippets (etc.), so it provides a rich attack surface.

[markus2330]

did I understand it correctly that we will get rid of website-backend completely, since it has not been working for a while?

Yes, I would suggest to not waste too much time on that. I tried myself to get it working again but much more work is needed. Furthermore, it depends on several C++ libs which all are also outdated and would need upgrades. So best we simply remove the parts in the website related to the snippet sharing and avoid having this backend. The WebUI is much more fun anyway. Better to have this running again.

get rid of website-backend completely

Yes, I think this is the best option.