* Granting execute permission for gradlew
In https://github.com/yashovardhan99/HealersDiary, while testing this action, I noticed `./gradlew build` fails because it does not have execute permissions. Adding the execute permissions using `chmod` fixes this issue.
* fixing line endings
This should fix it
* Renormalizing changes
This workflow will build and push a new container image to Alibaba Cloud Container Reigstry (ACR),
and then will deploy it to Alibaba Cloud Container Service for Kubernetes (ACK), when a release is created.
If the workflow is going to split restore, build, and test into separate
steps, each should use the result of the prior. Build was invoked with
`--no-restore` but test was restoring, building, and then testing.
Noticed that this version of setup-ruby causes problems with the `set-env` deprecation. This just bumps it up to the latest commit on https://github.com/ruby/setup-ruby/
Python 3.10 is coming soon, and this will cause problems with the code as currently written. The python versions are written as floats and not strings, which will mean that 3.10 == 3.1, which is going to be very surprising.
it looks like someone tried to use '' to make a ' happen for the possessive tense of users. But that messes up the quoting:
issue-message: 'Message that will be displayed on users'' first issue'
pr-message: 'Message that will be displayed on users'' first pr'
It should be:
issue-message: 'Message that will be displayed on the first issue for that user'
pr-message: 'Message that will be displayed on the first pr for that user'
(this gets rid of the spurious quotes, but also doesn't introduce any grammatical errors)
It was a very bad impression to have a simple script designed to welcome folks be broken by default.
With GitHub Packages everything is ok, but we had a problem with "bearer" in the RubyGems step.
We solved when we removed the bearer in the ruby gem step.
Is it ok?
Repo with our test (https://github.com/rubynetti/amico-db)
D is a statically and strongly typed, multi-paradigm, general-purpose native programming language.
D is fully open-source and maintained by a volunteer community.
For more information, see https://dlang.org
This patch adds a minimal workflow that allows users to compile D projects that use DUB,
the official D package manager and build tool.
The workflow uses the community-maintained `setup-dlang` action,
which can install any version of `dmd` (the reference compiler),
or `ldc` (the LLVM-based, performance oriented compiler,
on any of the three platforms currently supported by Github free runners.
Support for GDC is not yet implemented.
The logo used (d.svg) originates from
https://github.com/dlang/dlang.org/blob/master/images/dlogo_2015.svg
and is available under the BSL-1.0 license
(https://github.com/dlang/dlang.org/blob/master/LICENSE.txt)
Co-Authored-By: Mathias Lang <pro.mathias.lang@gmail.com>
This fixes warning:
Input 'version' has been deprecated with message: The version property will not be supported after October 1, 2019. Use ruby-version instead
When running this action, it will show steps like "Set up job", "Initialize containers" and "Complete job", which are not in Title Case. Nor is "Set up Elixir".
(Some steps like "Post Restore cache" are some sort of half-Title Case, but they seem to be in the minority.)
This patch adds support for deploying an application to IKS
by performing the following steps:
1. Downloading and installing the IBM Cloud CLI,
2. Building locally with Docker,
3. Pushing to ICR (IBM Container Registry), and
4. Deploying with kubectl to IKS
Co-authored-by: JJ Asghar <jjasghar@gmail.com>
Signed-off-by: Steve Martinelli <s.martinelli@gmail.com>
This workflow assumes an App Service web app has already been created and that a user knows how to obtain the desired input values. This cannot be assumed. Therefore I have included references to the relevant documentation.
We should have consistent line endings in our repository; now that we
have a .gitattributes file, update the repository contents to match
expectations.
The setup-node action will default the scope to the correct user (the repo owner), so we do not need to explicitly include it in the workflow. Removing it ensures that the starter template is easier for people to use; now there are no changes necessary to get started. https://github.com/actions/setup-node/blob/master/src/authutil.ts#L26
https://github.com/Licsber/opencv-docker/runs/514244582?check_suite_focus=true
Push image:
Error parsing reference: "docker.pkg.github.com/Licsber/opencv-docker/opencv:latest" is not a valid repository/tag: invalid reference format: repository name must be lowercase
My username contains uppercase characters, this make push failed.
So fix the bug by change all uppercase in IMAGE_ID to lowercase.
2.2 is no longer supported, so moving to latest SDK released for .NET core which supports and encourages LTS runtime version as well as down-level building.
The google.yml deployment workflow starter hardcoded the registry hostname as `gcr.io` even though there are other possible registry hostnames. It also hardcoded the deployment name. This puts them in env variables and adds to the comments that they need to be adjusted by the user.
There was no Code of Conduct in this Repository, so it points to the one given as proposal in the Issue Template.
There is a Licence, however the link was broken for me too.
* Use separate steps for install, build and test
Having separate steps makes it easier to determine what failed.
Switching from `npm ci` to `npm install` because the Windows image uses node v8.10.0 and npm v5.6.0. `ci` was introduced in npm v5.7.0.
See https://github.com/actions/virtual-environments/issues/88
* Remove `name`
It was pointed out (https://github.com/actions/labeler/issues/18) that when using the labeler from the starter-workflow, it's not clear that there is more work to do to configure the action. Add information and link to the action's README.
Add the `-B` (batch mode) to the `mvn` command line. In interactive mode maven prints many lines of download progress output filling the console output with thousands of useless lines. Ideally the github-actions console would interpret `\r' as carriage return (go back to the beginning of the current line and overwrite it). As long as that is not the case using `-B` is a good workaround.
rebar3 no longer has a separate step for fetching dependencies so
this step is removed. Common Test is enabled in the test run so it
will run all tests.
The Erlang docker image is used instead of ubuntu because ubuntu
has no package for rebar3.
about: Captures all the information and tasks required to onboard a 3rd party project into Code Scanning
title: 'Code Scanning Partner: '
labels: 'code scanning'
assignees: ''
---
:wave: Thanks for your interest in integrating with Code Scanning! To ensure a swift onboarding of your integration, please provide the following `Requested information` and complete the `Action items` below:
## Requested information
- [ ] Name of your integration:
- [ ] Name of your product / company:
- [ ] Description of your integration:
- [ ] Languages supported by your integration:
- [ ] [For integrations leveraging GitHub Actions] PR for your proposed workflow:
- [ ] URL to an SVG logo representing your integration / product / company:
## Action items
- [ ] Apply to join the GitHub Technology Partner Program: [partner.github.com/apply](https://partner.github.com/apply?partnershipType=Technology+Partner)
- [ ] Develop your integration, by _either_ [following this guide for GitHub Actions](https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github#uploading-a-code-scanning-analysis-with-github-actions), or [integrating directly with the REST API](https://docs.github.com/en/rest/reference/code-scanning#upload-a-sarif-file)
- [ ] [For integrations leveraging GitHub Actions] Submit a PR in this repo for your proposed starter workflow. The workflow should:
- [ ] Live in [the `code-scanning` directory](https://github.com/actions/starter-workflows/tree/main/code-scanning)
- [ ] Have a filename that is in accordance with your product / service / business name, in [_kebab-cased_ format](https://en.wikipedia.org/wiki/Kebab_case), with a `.yml` file extension
- [ ] Include comments describing the workflow’s behavior ([example](https://github.com/actions/starter-workflows/blob/c59b62dee0eae1f9f368b7011cf05c2fc42cf084/code-scanning/codeql.yml#L1-L11))
- [ ] Trigger on push, pull_request, and schedule events ([example](https://github.com/actions/starter-workflows/blob/c59b62dee0eae1f9f368b7011cf05c2fc42cf084/code-scanning/codeql.yml#L14-L21))
- [ ] Reference your GitHub Action using a 40-char commit SHA (e.g. `uses: github/codeql-action@a3a8231e64d3db0e7da0f3b56b9521dcccdfe412`)
- [ ] Update the `Requested information` above, ensuring all details are correct
- [ ] When ready, please ping `@actions/advanced-security-code-scanning` in a comment below, for a review :bow:
This repository contains configuration for what users see when they click on the `Actions` tab and the setup page for Code Scanning.
It is not:
* A playground to try out scripts
* A place for you to create a workflow for your repository
---
**Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.**
---
In the workflow and properties files:
- [ ] The workflow filename of CI workflows should be the name of the language or platform, in lower case. Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
The workflow filename of publishing workflows should be the name of the language or platform, in lower case, followed by "-publish".
- [ ] Includes a matching `ci/properties/*.properties.json` file.
- [ ] Use sentence case for the names of workflows and steps, for example "Run tests".
- [ ] The name of CI workflows should only be the name of the language or platform: for example "Go" (not "Go CI" or "Go Build")
- [ ] Include comments in the workflow for any parts that are not obvious or could use clarification.
- [ ] CI workflows should run on `push` to `branches: [ $default-branch ]` and `pull_request` to `branches: [ $default-branch ]`.
- [ ] Packaging workflows should run on `release` with `types: [ created ]`.
- [ ] Code Scanning workflows should run on `push` to `branches: [ $default-branch, $protected-branches ]` and `pull_request` to `branches: [ $default-branch ]`. We also recommend a `schedule` trigger of `cron: $cron-weekly`.
Some general notes:
- [ ] This workflow must only use actions that are produced by GitHub, [in the `actions` organization](https://github.com/actions), **or**
- [ ] This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be [published to the GitHub Marketplace](https://github.com/marketplace?type=actions). We recommend that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:
```
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
```
- [ ] Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
- [ ] Automation and CI workflows cannot be dependent on a paid service or product.
Thank you 🙇 for this request. This request has been classified as a feature by the maintainers.
We take all the requests for features seriously and have passed this on to the internal teams for their consideration.
Because any feature requires further maintenance and support in the long term by this team, we would like to exercise caution into adding new features. If this feature is something that can be implemented independently, please consider forking this repository and adding the feature.
Sorry, but we'd like to keep issues related to code in this repository. Thank you 🙇
If you have questions about writing workflows or action files, then please [visit the GitHub Community Forum's Actions Board](https://github.community/t5/GitHub-Actions/bd-p/actions)
If you are having an issue or question about GitHub Actions then please [contact customer support](https://help.github.com/en/articles/about-github-actions#contacting-support)
Hi there 👋 We are excited that you want to contribute a new workflow to this repo. By doing this you are helping people get up and running with GitHub Actions and that's cool 😎.
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](https://github.com/actions/starter-workflows/blob/main/LICENSE).
Please note that this project is released with a [Contributor Code of Conduct](
https://github.com/actions/.github/blob/main/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
**At this time we are only accepting new starter workflows for Code Scanning**
### Previous guidelines for new starter workflows.
Before merging a new workflow, the following requirements need to be met:
- Should be as simple as is needed for the service.
- There are many programming languages and tools out there. Right now we don't have a page that allows for a really large number of workflows, so we do have to be a little choosy about what we accept. Less popular tools or languages might not be accepted.
- Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
- Automation and CI workflows cannot be dependent on a paid service or product.
- We recommend that Actions outside of the `actions` organization be pinned to a specific SHA.
These are the workflow files for helping people get started with GitHub Actions. They're presented whenever you start to create a new GitHub Actions workflow.
These are the workflow files for helping people get started with GitHub Actions.
**If you want to get started with GitHub Actions, you can use these starter workflows by clicking the "Actions" tab in the repository where you want to create a workflow.**
* [automation](automation): solutions for automating workflows.
* [code-scanning](code-scanning): starter workflows for [Code Scanning](https://github.com/features/security)
* [icons](icons): svg icons for the relevant template
Each workflow must be written in YAML and have a `.yml` extension. They also need a corresponding `.properties.json` file that contains extra metadata about the workflow (this is displayed in the GitHub.com UI).
For example: `ci/python-django.yml` and `ci/python-django.properties.json`.
For example: `ci/django.yml` and `ci/properties/django.properties.json`.
# This workflow will build and push a node.js application to an Azure Web App when a release is created.
#
# This workflow assumes you have already created the target Azure App Service web app.
# For instructions see https://docs.microsoft.com/azure/app-service/app-service-plan-manage#create-an-app-service-plan
#
# To configure this workflow:
#
# 1. For Linux apps, add an app setting called WEBSITE_WEBDEPLOY_USE_SCM and set it to true in your app **before downloading the file**.
# For more instructions see: https://docs.microsoft.com/azure/app-service/configure-common#configure-app-settings
#
# 2. Set up a secret in your repository named AZURE_WEBAPP_PUBLISH_PROFILE with the value of your Azure publish profile.
# For instructions on obtaining the publish profile see: https://docs.microsoft.com/azure/app-service/deploy-github-actions#configure-the-github-secret
#
# 3. Change the values for the AZURE_WEBAPP_NAME, AZURE_WEBAPP_PACKAGE_PATH and NODE_VERSION environment variables (below).
#
# For more information on GitHub Actions for Azure, refer to https://github.com/Azure/Actions
# For more samples to get started with GitHub Action workflows to deploy to Azure, refer to https://github.com/Azure/actions-workflow-samples
on:
release:
types:[created]
env:
AZURE_WEBAPP_NAME:your-app-name # set this to your application's name
AZURE_WEBAPP_PACKAGE_PATH:'.'# set this to the path to your web app project, defaults to the repository root
NODE_VERSION:'10.x'# set this to the node version to use
# This workflow will build a docker container, publish it to Google Container Registry, and deploy it to GKE when a release is created
#
# To configure this workflow:
#
# 1. Ensure that your repository contains the necessary configuration for your Google Kubernetes Engine cluster, including deployment.yml, kustomization.yml, service.yml, etc.
#
# 2. Set up secrets in your workspace: GKE_PROJECT with the name of the project and GKE_SA_KEY with the Base64 encoded JSON service account key (https://github.com/GoogleCloudPlatform/github-actions/tree/docs/service-account-key/setup-gcloud#inputs).
#
# 3. Change the values for the GKE_ZONE, GKE_CLUSTER, IMAGE, and DEPLOYMENT_NAME environment variables (below).
#
# For more support on how to run the workflow, please visit https://github.com/google-github-actions/setup-gcloud/tree/master/example-workflows/gke
name:Build and Deploy to GKE
on:
release:
types:[created]
env:
PROJECT_ID:${{ secrets.GKE_PROJECT }}
GKE_CLUSTER: cluster-1 # TODO:update to cluster name
GKE_ZONE: us-central1-c # TODO:update to cluster zone
DEPLOYMENT_NAME: gke-test # TODO:update to deployment name
IMAGE:static-site
jobs:
setup-build-publish-deploy:
name:Setup, Build, Publish, and Deploy
runs-on:ubuntu-latest
steps:
- name:Checkout
uses:actions/checkout@v2
# Setup gcloud CLI
- uses:google-github-actions/setup-gcloud@v0.2.0
with:
service_account_key:${{ secrets.GKE_SA_KEY }}
project_id:${{ secrets.GKE_PROJECT }}
# Configure Docker to use the gcloud command-line tool as a credential
# helper for authentication
- run:|-
gcloud --quiet auth configure-docker
# Get the GKE credentials so we can deploy to the cluster
if [ $scheme = default ]; then scheme=$(cat default); fi
if [ "`ls -A | grep -i \\.xcworkspace\$`" ]; then filetype_parameter="workspace" && file_to_build="`ls -A | grep -i \\.xcworkspace\$`"; else filetype_parameter="project" && file_to_build="`ls -A | grep -i \\.xcodeproj\$`"; fi
if [ $scheme = default ]; then scheme=$(cat default); fi
if [ "`ls -A | grep -i \\.xcworkspace\$`" ]; then filetype_parameter="workspace" && file_to_build="`ls -A | grep -i \\.xcworkspace\$`"; else filetype_parameter="project" && file_to_build="`ls -A | grep -i \\.xcodeproj\$`"; fi
"description":"Create and test a Python package on multiple Python versions.",
"iconName":"python",
"categories":["Python"]
}
{
"name":"Python package",
"description":"Create and test a Python package on multiple Python versions.",
"iconName":"python",
"categories":["Python"]
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.