[INFRA] Streamline the way we notify other repositories when a new version is available #2864
Closed
5 tasks done
Labels
chore
Build, CI/CD or repository tasks (issues/PR maintenance, environments, ...)
Milestone
Current status and problems
Historically, when a new tag was created, we built the navigation demo and then notified the repository of examples that the demo was available.Then, when we introduced the R package, we notify it of a new release when the npm publish was done (it requires to download the IIFE bundle from the npm package).
At a first glance, we see that we notify the repositories at a different pace, whereas we should notify them at the same time. And this should be done when we are sure that the npm package is published. If this fails, we generally fix the problem and create a new release.
But there are more important issues with the current way of doing things.
In the repository of examples, the projects' package.json files are updated when a new version is available. This triggers a build of these projects, which requires the new package version to be available on npmjs.
By notifying the repository of examples after a tag (and building the navigation demo), we have no guarantee that the npm package is available for building the projects. The "npm publish" workflow can take time to run, or can be queued because all GitHub runners are already running other jobs.
In the past, errors occurred several times because of that. This requires running the GitHub workflow again, which is boring and slows down the release.
This has been even more critical since we have merged process-analytics/bpmn-visualization-examples#541: the first step of the GitHub workflow updating the version downloads the npm package (to compute SubResource Integrity). There are more chances than ever that it is not available at that time.It occurs during the first update done after this PR was merged.
See errors in https://github.com/process-analytics/bpmn-visualization-examples/actions/runs/6222658937/job/16887034563:
Here are the logs of the npm publish process in the
bpmn-visualization
repository : they show that the package is published more than one minute later, so the update fails for sure (see https://github.com/process-analytics/bpmn-visualization-js/actions/runs/6222648900/job/16887005367):Proposals
The examples repository must be notified of new version availability only when the npm package is published.
It also requires to retrieve the "navigation demo".
Current implementation
Proposal 1
IMPORTANT: this will not be implemented, see "Proposal 2"
A first solution could be like the following:
repository_dispatch
at the end of the "npm publish" workflow including the tag/version.workflow_dispatch
for manual replayrepository_dispatch
to all repositories (using a matrix configuration - array) requiring to be notified that a new version is available on npm (for now, bpmn-visualization-examples, for others, see below)Note: In the description above, the "new workflow" could be the existing workflow building the navigation demo that we would update with the proposal. It would probably have to be renamed to match what it achieves. Note that this involves modifying the event sent to the example repository, as it contains the name of the workflow that stores the navigation demo artifact.
Proposal 1
Proposal 2
IMPORTANT: this is the proposal that will be implemented
Overview
Proposal 2
Repositories to notify when a new version is available
While we currently notify the repository of examples and
bpmnVisualizationR
, other repositories may also require to be notified when a new version is available.Managed with dependabot: if there is an urgent need for an update, it can be run manually:
Not possible to managed with dependabot
bpmnVisualizationR
: require to download the IIFE bundleTo check
Tasks
The text was updated successfully, but these errors were encountered: