Conversation
jabrah
left a comment
jabrah
left a comment
There was a problem hiding this comment.
For an initial commit, this should be OK.
We'll need to touch all of the workflows mentioned here and add on.workflow_call that will look similar to on.workflow_dispatch (https://docs.github.com/en/actions/using-workflows/reusing-workflows#creating-a-reusable-workflow).
After that, we'll need to make sure releases are ordered and timed correctly. Will need to find a reasonable way of waiting on Java releases for their release artifacts to be available in Maven Central, but we can figure that out in subsequent iterations as long as it's understood that we can't use this workflow until all of those are taken care of.
|
The initial draft was pretty close. The Java release portions were the only ones that need to be rewritten as a stand-alone workflow to support local/offline dependency resolution (though currently untested). Some explicit job dependencies were also called out to allow several jobs to run concurrently to help speed things along |
jabrah
changed the title
|
Do we need to use the offline flag in order to use the maven builds that aren't currently in maven central? Can we make a template for the individual steps / refactor while also keeping the local builds in one single environment for the dependencies to access? |
|
Will need release workflows to be externally callable (adding
We'll need to determine the scoping of the GH provided token, whether we need to add specific credentials for letting the external workflows make commits in their respective repositories. |
|
Please retry analysis of this Pull-Request directly on SonarQube Cloud |
|
|
No longer relevant. |
3 participants
No description provided.