create release in workflow => attach bundle

[mki-c2c]

JIRA issue

https://jira.camptocamp.com/browse/GSLUX-635

Description

when a version of V4 is tagged (ex GSLUX-635_5278bb4fbd7496cbb092087899d106256e3154a0) the CI will automatically create a release based on this tag and upload a targz ed bundle of the distributed files

The releases created in this way can be used in v3 from Geoportail-Luxembourg/geoportailv3#3180 onwards

Screenshots

[github-actions]

GitHub Pages links: * Luxembourg-geoportail: https://geoportail-luxembourg.github.io/luxembourg-geoportail/GSLUX-635_create_release_CI/

[tkohr]

Thanks for the workflow @mki-c2c ! I think it'd be nice to create the bundle on merges on main as well and make it accessible without the need to be decompressed (maybe on a dedicated branch or via npm).

In gn-ui we publish the lib on npm on every merge for instance.

The web components are published on dedicated branches while the dev branch always stays the same (so this might not work in the same way for our v3 that needs branch, tag or commit changes to update its v4). But maybe we can come up with something similar.

[AlitaBernachot]

Why building a release on a tag?
This task should have been discussed with the team before.

[AlitaBernachot]

version 16?

[mki-c2c]

well this was copied from the GH-pages script, what version should we use ? does it matter for building the bundle ?

[mki-c2c]

Why building a release on a tag? This task should have been discussed with the team before.

Yes, I wanted to present a POC to be discussed, Arnaud's idea was great to put the bundle outside the repo. And github requires a tag to create a release, so the version has to be tagged. I thought also of cleanup which removes all temprary tags and releases when the branch is merged.

[tkohr]

Thanks for this nice improvement @mki-c2c ! Tested in v3 and works well with (dev) and without (git) docker compose override. (Just needed to recreate the /bundle dir manually and had to restart the compo for the override to work properly).

I think we should still add some doc to the readme (especially for the naming convention for tags, in particular since it's not yet automated). Wondering if it's very practical to make the branch name part of the tag as it will become part of the list git proposes on git checkout GSLUX-XXX, like:

git checkout GSLUX-635_
GSLUX-635_5278bb4fbd7496cbb092087899d106256e3154a0   GSLUX-635_create_release_CI
GSLUX-635_create_release_CI_929e4aa 
GSLUX-635_5eef06fbd2b691b10bc67715bf194fbb13be5512   GSLUX-635_create_release_CI_05077da                  GSLUX-635_create_release_CI_b51758e 
GSLUX-635_877f1af7315cefaf3f7ef447453ad244e15330eb   GSLUX-635_create_release_CI_6606389

Maybe something like

• PR-XX-commithash for tags on branches
• PR-XX-merged-commithash for tags on main
• 1.0.0 for explicit "manual" releases
  would be more practical? WDYT?

I see there are conflicts in the bundle even thought they have been deleted. I guess a rebase will fix this.

[tkohr]

Could probably be done in one step ?

      - name: Build and Pack Prod Library
        shell: bash
        run: |
          npm ci
          npm run build:lib:prod
          npm pack