Skip to content

Don't update jmxfetch integrations submodule during build #9150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 22, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions .github/workflows/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,14 @@ _Action:_ Build the Java Client Library and runs [the system tests](https://gith

_Recovery:_ Manually trigger the action on the desired branch.

### update-jmxfetch-submodule [🔗](update-jmxfetch-submodule.yaml)

_Trigger:_ Monthly or manually

_Action:_ Creates a PR updating the git submodule at dd-java-agent/agent-jmxfetch/integrations-core

_Recovery:_ Manually trigger the action again.

## Maintenance

GitHub actions should be part of the [repository allowed actions to run](https://github.com/DataDog/dd-trace-java/settings/actions).
Expand Down
44 changes: 44 additions & 0 deletions .github/workflows/update-jmxfetch-submodule.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
name: Update jmxfetch integrations submodule

on:
schedule:
- cron: '0 0 1 * *'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest weekly, early on monday

Suggested change
- cron: '0 0 1 * *'
- cron: '0 2 * * 1'

workflow_dispatch:

jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # 4.2.2

- name: Update Submodule
run: |
git submodule update --remote -- dd-java-agent/agent-jmxfetch/integrations-core
- name: Download ghcommit CLI
run: |
curl https://github.com/planetscale/ghcommit/releases/download/v0.1.48/ghcommit_linux_amd64 -o /usr/local/bin/ghcommit -L
chmod +x /usr/local/bin/ghcommit
- name: Pick a branch name
id: define-branch
run: echo "branch=ci/update-jmxfetch-submodule-$(date +'%Y%m%d')" >> $GITHUB_OUTPUT
- name: Create branch
run: |
git checkout -b ${{ steps.define-branch.outputs.branch }}
git push -u origin ${{ steps.define-branch.outputs.branch }} --force
- name: Commit and push changes
env:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
run: |
ghcommit --repository ${{ github.repository }} --branch ${{ steps.define-branch.outputs.branch }} --add dd-java-agent/agent-jmxfetch/integrations-core --message "Update agent-jmxfetch submodule"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Wouldn't it be better to use git itself, rather than using a third party executable ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I copied this from another workflow. It's what's used in Update Gradle Dependencies and Update Docker Build Image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be better to use git itself, rather than using a third party executable ?

You would need to create signed commits for them to be merged.
That will required to setup commit signature on git CLI first.
I use the GH API instead in order to build signed commits.

- name: Create pull request
env:
GH_TOKEN: ${{ github.token }}
run: |
gh pr create --title "Update agent-jmxfetch submodule" \
--base master \
--head ${{ steps.define-branch.outputs.branch }} \
--label "comp: tooling" \
--label "type: enhancement" \
--label "tag: no release notes" \
--body "This PR updates the agent-jmxfetch submodule."
2 changes: 2 additions & 0 deletions .gitlab-ci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -138,6 +138,8 @@ default:
KUBERNETES_MEMORY_LIMIT: 8Gi
CACHE_TYPE: lib #default
RUNTIME_AVAILABLE_PROCESSORS_OVERRIDE: 4 # Runtime.getRuntime().availableProcessors() returns incorrect or very high values in Kubernetes
GIT_SUBMODULE_STRATEGY: normal
GIT_SUBMODULE_DEPTH: 1
cache:
- key: '$CI_SERVER_VERSION-$CACHE_TYPE' # Dependencies cache. Reset the cache every time gitlab is upgraded. ~Every couple months
paths:
Expand Down
1 change: 0 additions & 1 deletion dd-java-agent/agent-jmxfetch/build.gradle
Original file line number Diff line number Diff line change
Expand Up @@ -97,7 +97,6 @@ tasks.register('copyMetricConfigs', CopyMetricConfigsTask) {
description 'Copy metrics.yaml files from integrations-core into resources'
inputDirectory = file("$projectDir/integrations-core")
outputDirectory = file("$buildDir/integrations-core-resources")
dependsOn 'submodulesUpdate'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may also want to do that during a release.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. submodulesUpdate checks out the submodule at the pinned version. It doesn't actually update it to latest.

Gitlab can check out the submodule automatically so it is unneeded to do it in Gradle

}

processResources {
Expand Down