chore: separate workflows for prs releases and tags

[jenniferarnesen]

PR workflow: verify-pr.yml
This workflow triggers on pull request actions only. It verifies that the PR code passes build, lint, test, and e2e.

Release workflow: release.yml
This workflow only runs on pushes to the master branch since this is the only release branch. Every release involves 2 commits to master:

1. squash merging the PR
2. the release workflow pushes a new commit with version change in package.json and CHANGELOG.md, e.g. the [skip release] commit

The release workflow triggers for both pushes to master listed above. But we only want the jobs to run for the first push. Therefore all jobs (e.g. build, lint, test, e2e, release, report) check that the commit is not a "[skip release]". In the case of the second commit ([skip release]) the workflow will therefore complete successfully without running any jobs.

The semantic-release workflow steps are found in .releaserc. Previously @dhis2/action-semantic-release was used but this was overkill for our needs and difficult to make changes to. Therefore, we created our own semantic-release steps in .releaserc:

1. commit-analyzer: Determines the next app version
2. release-notes-generator: Generates the new release notes
3. changelog: Updates CHANGELOG.md with the generated release notes
4. npm: Updates package.json with the new version number. Does not publish to npm since private: true in package.json
5. exec: Runs yarn build which updates all version number references in the bundle
6. git: creates commit number "2" (mentioned above) with just CHANGELOG.md and package.json and pushes it to the remote
7. github: pushes the bundle to the github repo as a new release and adds a tag

After semantic-release is complete, the bundle is then published to AppHub so that it is actually available to all users. Because of the addition of the exec yarn build step, all references to the version in the bundle should be the same, thus fixing the annoying bug where the old version displays in the instance after installing the later version.

If any point in the release fails, then a failure message is sent to slack. If the release step succeeds, then a success message is posted to slack that includes the new version number and the release notes.

Publish to d2-ci: publish-to-d2-ci.yml
This workflow publishes the build to d2-ci in the following cases:

1. The [skip release] commit on master
2. Git tags
   Fail message is sent to slack if the publish failed

[dhis2-bot]

🚀 Deployed on https://pr-3276--dhis2-maps.netlify.app

[HendrikThePendric]

Great work @jenniferarnesen. I've left a few comments we should discuss when you get back.

Perhaps something we could also discuss then, is how we can share this across our analytics repos. Or perhaps before we get to that, discuss if we want to actually do this. As a team we have:

• 4 react apps
• 2 ExtJS apps
• 1 NPM library

I guess sharing the workflow config could make sense for these 4 react-apps. But both the maps-app and dashboards-app have some special requirements (?). Just copy-pasting things across repos might actually be a more suitable solution in this case, since it offers a much higher level of flexibility and prevents us from having to maintain this shared config.

[jenniferarnesen]

Great work @jenniferarnesen. I've left a few comments we should discuss when you get back.

Perhaps something we could also discuss then, is how we can share this across our analytics repos. Or perhaps before we get to that, discuss if we want to actually do this. As a team we have:

• 4 react apps
• 2 ExtJS apps
• 1 NPM library

I guess sharing the workflow config could make sense for these 4 react-apps. But both the maps-app and dashboards-app have some special requirements (?). Just copy-pasting things across repos might actually be a more suitable solution in this case, since it offers a much higher level of flexibility and prevents us from having to maintain this shared config.

My approach is to get this merged in maps-app, and give it a few release cycles to make sure it works the way we want it to. Then, we can generalize it, make shared workflows, etc and move our apps to it.

[HendrikThePendric]

I've re-reviewed, but would still like to resolve this conversation before merging.

[dhis2-bot]

🎉 This PR is included in version 100.6.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀