Create docker-image.yml

[flynnjustin24]

e30cbda# Creating a pull request Create a pull request to propose and collaborate on changes to a repository. These changes are proposed in a branch, which ensures that the default branch only contains finished and approved work. If you want to create a new branch for your pull request and do not have write permissions to the repository, you can fork the repository first. For more information, see Creating a pull request from a fork and About forks. You can specify which branch you'd like to merge your changes into when you create your pull request. Pull requests can only be opened between two branches that are different. > [!NOTE] > To open a pull request in a public repository, you must have write access to the head or the source branch or, for organization-owned repositories, you must be a member of the organization that owns the repository to open a pull request. You can link a pull request to an issue to show that a fix is in progress and automatically close the issue when the pull request is merged. For more information, see Linking a pull request to an issue. ## Changing the branch range and destination repository By default, pull requests are based on the parent repository's default branch. For more information, see About branches. If the default parent repository isn't correct, you can change both the parent repository and the branch with the drop-down lists. You can also swap your head and base branches with the drop-down lists to establish diffs between reference points. References here must be branch names in your GitHub repository. When thinking about branches, remember that the base branch is where changes should be applied, the head branch contains what you would like to be applied. When you change the base repository, you also change notifications for the pull request. Everyone that can push to the base repository will receive an email notification and see the new pull request in their dashboard the next time they sign in. When you change any of the information in the branch range, the Commit and Files changed preview areas will update to show your new range. > [!TIP] > > * Using the compare view, you can set up comparisons across any timeframe. For more information, see Comparing commits. > * Project maintainers can add a pull request template for a repository. Templates include prompts for information in the body of a pull request. For more information, see About issue and pull request templates. ## Creating the pull request

1. On GitHub, navigate to the main page of the repository. 2. In the "Branch" menu, choose the branch that contains your commits. 3. Above the list of files, in the yellow banner, click Compare & pull request to create a pull request for the associated branch. 4. Use the base branch dropdown menu to select the branch you'd like to merge your changes into, then use the compare branch drop-down menu to choose the topic branch you made your changes in. 5. Type a title and description for your pull request. 6. To create a pull request that is ready for review, click Create Pull Request. To create a draft pull request, use the drop-down and select Create Draft Pull Request, then click Draft Pull Request. If you are the member of an organization, you may need to request access to draft pull requests from an organization owner. See About pull requests. > [!TIP] > After you create a pull request, you can ask a specific person to review your proposed changes. For more information, see Requesting a pull request review. After your pull request has been reviewed, it can be merged into the repository.

> [!NOTE] > To learn more about GitHub CLI, see About GitHub CLI. To create a pull request, use the gh pr create subcommand. shell gh pr create To assign a pull request to an individual, use the --assignee or -a flags. You can use @me to self-assign the pull request. shell gh pr create --assignee "@octocat" To specify the branch into which you want the pull request merged, use the --base or -B flags. To specify the branch that contains commits for your pull request, use the --head or -H flags. shell gh pr create --base my-base-branch --head my-changed-branch To include a title and body for the new pull request, use the --title and --body flags. shell gh pr create --title "The bug is fixed" --body "Everything works again" To mark a pull request as a draft, use the --draft flag. shell gh pr create --draft To add a labels or milestones to the new pull request, use the --label and --milestone flags. shell gh pr create --label "bug,help wanted" --milestone octocat-milestone To add the new pull request to a specific project, use the --project flag. shell gh pr create --project octocat-project To assign an individual or team as reviewers, use the --reviewer flag. shell gh pr create --reviewer monalisa,hubot --reviewer myorg/team-name To create the pull request in your default web browser, use the --web flag. shell gh pr create --web

1. Click Preview Pull Request. GitHub Desktop will open a preview dialog showing the diff of the changes between your current branch and the base branch.

Alternatively, to go straight to GitHub to create your pull request, select the dropdown icon and click Create Pull Request. 2. Confirm that the branch in the base: dropdown menu is the branch where you want to merge your changes. GitHub Desktop will advise you whether the current branch can be automatically merged into the base branch. 3. Click Create Pull Request. GitHub Desktop will open your default browser to take you to GitHub. 4. Type a title and description for your pull request. 5. To create a pull request that is ready for review, click Create Pull Request. To create a draft pull request, use the drop-down and select Create Draft Pull Request, then click Draft Pull Request. If you are the member of an organization, you may need to request access to draft pull requests from an organization owner. See About pull requests.

1. Once you've committed changes to your local copy of the repository, click the Create Pull Request icon. 2. Check that the local branch and repository you're merging from, and the remote branch and repository you're merging into, are correct. Then give the pull request a title and a description. 3. Click Create. For more information on creating pull requests in GitHub Codespaces, see Using GitHub Codespaces for pull requests.

## Making changes to files in your pull request After you have opened your pull request, you can continue making changes to the files by adding new commits to your head branch.

You can also make changes to files on the GitHub website. 1. On GitHub, navigate to a pull request in a repository. 2. On the pull request, click Files changed. 3. Scroll down to the file you want to make changes to. * If the pull request has a lot of files, you can use the filter to locate the file. See Filtering files in a pull request. 4. Above the file you want to change, click . 5. In the menu, click Edit file. 6. Make your changes in the editor and when committing your change, choose to commit directly back to your head branch.

## Further reading * Creating a pull request from a fork * Keeping your pull request in sync with the base branch * Changing the base branch of a pull request * Creating an issue * Assigning issues and pull requests to other GitHub users * Writing on GitHub.config/CredScanSuppressions.json- name: yq - portable yaml processor
uses: mikefarah/yq@v4.9.4curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -v -b /usr/local/bincurl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bingit clone https://github.com/trufflesecurity/trufflehog.git
cd trufflehog; go installDownload and unpack from https://github.com/trufflesecurity/trufflehog/releasesdocker run --platform linux/arm64 --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keysdocker run --rm -it -v "${PWD}:/pwd" trufflesecurity/trufflehog github --repo https://github.com/trufflesecurity/test_keysdocker run --rm -it -v "%cd:/=%:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys- uses: actions/upload-artifact@v4
with:
# Name of the artifact to upload.
# Optional. Default is 'artifact'
name:

# A file, directory or wildcard pattern that describes what to upload
# Required.
path:

# The desired behavior if no files are found using the provided path.
# Available Options:
#   warn: Output a warning but do not fail the action
#   error: Fail the action with an error message
#   ignore: Do not output any warnings or errors, the action does not fail
# Optional. Default is 'warn'
if-no-files-found:

# Duration after which artifact will expire in days. 0 means using default retention.
# Minimum 1 day.
# Maximum 90 days unless changed from the repository settings page.
# Optional. Defaults to repository settings.
retention-days:

# The level of compression for Zlib to be applied to the artifact archive.
# The value can range from 0 to 9.
# For large files that are not easily compressed, a value of 0 is recommended for significantly faster uploads.
# Optional. Default is '6'
compression-level:

# If true, an artifact with a matching name will be deleted before a new one is uploaded.
# If false, the action will fail if an artifact for the given name already exists.
# Does not fail if the artifact does not exist.
# Optional. Default is 'false'
overwrite:

# Whether to include hidden files in the provided path in the artifact
# The file contents of any hidden files in the path should be validated before
# enabled this to avoid uploading sensitive information.
# Optional. Default is 'false'
include-hidden-files:steps:

• run: mkdir -p path/to/artifact
• run: echo hello > path/to/artifact/world.txt
• uses: actions/upload-artifact@v4
  with:
  name: my-artifact
  path: path/to/artifact/world.txt- uses: actions/upload-artifact@v4
  with:
  name: my-artifact
  path: path/to/artifact/ # or path/to/artifact- uses: actions/upload-artifact@v4
  with:
  name: my-artifact
  path: path//[abc]rtifac?/*- uses: actions/upload-artifact@v4
  with:
  name: my-artifact
  path: |
  path/output/bin/
  path/output/test-results
  !path//*.tmp - name: Upload a Build Artifact
  uses: actions/upload-artifact@v6.0.0
  with:

  Artifact name

  name: # optional, default is artifact

  A file, directory or wildcard pattern that describes what to upload

  path:

  The desired behavior if no files are found using the provided path.

Available Options:
warn: Output a warning but do not fail the action
error: Fail the action with an error message
ignore: Do not output any warnings or errors, the action does not fail

if-no-files-found: # optional, default is warn
# Duration after which artifact will expire in days. 0 means using default retention.

Minimum 1 day. Maximum 90 days unless changed from the repository settings page.

retention-days: # optional
# The level of compression for Zlib to be applied to the artifact archive. The value can range from 0 to 9: - 0: No compression - 1: Best speed - 6: Default compression (same as GNU Gzip) - 9: Best compression Higher levels will result in better compression, but will take longer to complete. For large files that are not easily compressed, a value of 0 is recommended for significantly faster uploads.

compression-level: # optional, default is 6
# If true, an artifact with a matching name will be deleted before a new one is uploaded. If false, the action will fail if an artifact for the given name already exists. Does not fail if the artifact does not exist.

overwrite: # optional, default is false
# If true, hidden files will be included in the artifact. If false, hidden files will be excluded from the artifact.

include-hidden-files: # optional, default is false

[karthiknadig]

This does not seems like it is addressing any specific issue. Please file a bug or refer a issue that you are addressing.

Closing this.