SERVER-216: new packaging system #401
Conversation
cinterloper
force-pushed
the
dev/SERVER-216
branch
from
904493a to
bd5b54c
Compare
cinterloper
requested review from
a-spiker,
arrowplum,
dwelch-spike,
kportertx and
pvinh-spike
arrowplum
left a comment
arrowplum
left a comment
There was a problem hiding this comment.
The way it works is nice but I think we want to change the trigger and the mac build
| workflow_dispatch: | ||
| push: | ||
| branches: | ||
| - 'dev/*' |
There was a problem hiding this comment.
I think we don't want to make a build for all pushes to any branch. Just merges to main or mergestto hotfix
There was a problem hiding this comment.
@kportertx I think this is any dev what we agreed on
Its now changed to what is in the link above (tools-packaging-common example workflow)
There was a problem hiding this comment.
@arrowplum these are all basically "release" branches.
The server uses dev/* for special "dev builds" that often provide additional instrumentation of occasionally a improvement urgently needed by a customer.
hotfix/* are used to collect hotfixes for various versions of the server - arguably this should have been called release/* but that decision is ancient history now.
There was a problem hiding this comment.
@cinterloper I'd thought we were going to have any commit to an active PR trigger a build. The idea was that we could open a draft PR when we need to provide another team early development access to a feature branch.
There was a problem hiding this comment.
@cinterloper realized I'm a bit tunnel vision on the server's usage. aerospike-admin doesn't use these prefixes, since they don't do hotfixes or dev builds. They just have master. Well I do see a fednow-dev-build so it does have dev builds just not following the server's convention.
@arrowplum would like more projects to follow https://conventional-branch.github.io/ - the server will need to be a bit different from this unless we change our conventions, we can deal with this later. By this convention, it would only be release/*, main, master, develop branches that need builds. I still think all PRs should have builds.
| required: false | ||
| type: string | ||
|
|
||
| jobs: |
There was a problem hiding this comment.
Can we do this with the reusable build workflow (and strip away much of the conditional (since it is for the tools 'meta' package) and the cache? Similar to https://github.com/aerospike/aql/pull/46/files#diff-004bcf41cd6b78932e3c9cfdcb3fcc79959f01eef1e685b8d8ad1b5da398dea7
There was a problem hiding this comment.
Will drop mac artifact from this pr
| - el10 | ||
| - amzn2023 | ||
| - debian12 | ||
| #- debian13 |
There was a problem hiding this comment.
Are we sure about the distros supported?
There was a problem hiding this comment.
These look correct with the exception of debian13 being commented out.
| sign-artifacts: | ||
| strategy: | ||
| matrix: | ||
| distro: |
There was a problem hiding this comment.
For later but a coalesce step after the build would let you not repeat the matrix for each job
There was a problem hiding this comment.
Yeah, will create a Jira improvement task for this
…correct triggers and re-enable debian 13
| - el10 | ||
| - amzn2023 | ||
| - debian12 | ||
| #- debian13 |
There was a problem hiding this comment.
These look correct with the exception of debian13 being commented out.
| echo "ENV_DISTRO is not set" | ||
| return | ||
| fi | ||
| chown -R root:root . |
There was a problem hiding this comment.
This seems like an odd thing to do - what directory does this execute from and why is this needed?
| workflow_dispatch: | ||
| push: | ||
| branches: | ||
| - 'dev/*' |
There was a problem hiding this comment.
@cinterloper realized I'm a bit tunnel vision on the server's usage. aerospike-admin doesn't use these prefixes, since they don't do hotfixes or dev builds. They just have master. Well I do see a fednow-dev-build so it does have dev builds just not following the server's convention.
@arrowplum would like more projects to follow https://conventional-branch.github.io/ - the server will need to be a bit different from this unless we change our conventions, we can deal with this later. By this convention, it would only be release/*, main, master, develop branches that need builds. I still think all PRs should have builds.
This PR integrates with shared workflows and packaging common to enable packaging and deployment to JFrog in Github Actions.
The Actions tab will show build results and link to JFrog artifacts
packaging common contains information about project setup and test cases