Conversation
…y replicating the existing beta workflow.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v6 | ||
|
|
||
| - uses: actions/setup-java@v5 | ||
| with: | ||
| distribution: 'zulu' | ||
| java-version: '21' | ||
|
|
||
| - name: Set build number | ||
| run: scripts/installer/custom-build-number ${{ github.event.inputs.buildlabel }} | ||
|
|
||
| - name: Get branch name | ||
| id: branch-name | ||
| uses: tj-actions/branch-names@v6 | ||
|
|
||
| - name: Build application war | ||
| run: mvn package | ||
|
|
||
| - name: Get war file name | ||
| working-directory: target | ||
| run: echo "war_file=$(ls *.war | head -1)">> $GITHUB_ENV | ||
|
|
||
| - name: Upload war artifact | ||
| uses: actions/upload-artifact@v7 | ||
| with: | ||
| name: built-app | ||
| path: ./target/${{ env.war_file }} |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI about 2 months ago
In general, the fix is to explicitly define a permissions block in the workflow (either at the top level or under the specific job) granting only the minimal scopes required. This documents the workflow’s needs and prevents it from unintentionally inheriting broader defaults (such as full read-write on repo contents).
For this particular workflow, it only needs to read repository contents (for checkout) and use artifacts. None of the steps push commits, modify issues, or interact with pull requests, so we can safely restrict GITHUB_TOKEN to contents: read. We should add a root-level permissions block near the top of .github/workflows/generate_war_file.yml, right after the name: (or before/after on:) so that it applies to all jobs, including the build job on line 12. No imports or additional methods are needed; this is purely a YAML configuration change.
Concretely, in .github/workflows/generate_war_file.yml, insert:
permissions:
contents: readbetween the name: and on: keys (or equivalently between on: and jobs:), keeping indentation consistent. This will satisfy CodeQL and enforce least privilege without changing the workflow’s behavior.
| @@ -1,5 +1,8 @@ | ||
| name: 'Generate dataverse war file' | ||
|
|
||
| permissions: | ||
| contents: read | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| inputs: |
…ble action Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…ain permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…nto extra_workflows
5 participants
What this PR does / why we need it:
The pr adds a couple of workflows, for deploying to internal, and for building a war file.
Note that I'm getting rid of the hard-coded "build" that follows the version number, when custom BuildNumber.properties is present.
I want it to be a generic custom label (not necessarily a Jenkins build number). I.e., the goal is not to be limited to
v. 6.10 build NNNN, but to be able to have something likev. 6.10 release buildorv. 6.10 official release- or something of that nature.When run without supplying a custom label,
scripts/installer/custom-build-numberwill continue with the legacy behavior, defaulting tobuild <branchname>-<checksum>Which issue(s) this PR closes:
Special notes for your reviewer:
Suggestions on how to test this:
Does this PR introduce a user interface change? If mockups are available, please link/include them here:
Is there a release notes update needed for this change?:
Additional documentation: