Today I am dealing with the topic of Github Actions. I am not familiar with the topic of CI.
At GitHub I want to create an action. For the time being I use the boilplate of GitHub. I don't understand what ubuntu-latest jobs: build: runs-on: ubuntu-latest means. In another tutorial I saw self-hosted. On the server I want to deploy is also ubuntu, but that has nothing to do with it, right?
Thank you very much for an answer, feedback, comments and ideas.
GitHub workflow yml
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the master branch
push:
branches: [ master ]
pull_request:
branches: [ master ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout#v2
# Runs a single command using the runners shell
- name: Run a one-line script
run: echo Hello, world!
# Runs a set of commands using the runners shell
- name: Run a multi-line script
run: |
echo Add other actions to build,
echo test, and deploy your project.
The runner is the application that runs a job and its steps from a GitHub Actions workflow.
It is used by GitHub Actions in the hosted virtual environments, or you can self-host the runner in your own environment.
Basically, GitHub-hosted runners offer a quicker, simpler way to run your workflows, while self-hosted runners are a highly configurable way to run workflows in your own custom environment.
Quoting the Github documentation:
GitHub-hosted runners:
- Receive automatic updates for the operating system, preinstalled packages and tools, and the self-hosted runner application.
- Are managed and maintained by GitHub.
- Provide a clean instance for every job execution.
- Use free minutes on your GitHub plan, with per-minute rates applied after surpassing the free minutes.
Self-hosted runners:
- Receive automatic updates for the self-hosted runner application only. You are responsible for updating the operating system and all other software.
- Can use cloud services or local machines that you already pay for.
- Are customizable to your hardware, operating system, software, and security requirements.
- Don't need to have a clean instance for every job execution.
Are free to use with GitHub Actions, but you are responsible for the cost of maintaining your runner machines.
You can also see on the link shared above the following table showing the available Github hosted runners with their associated label (such as ubuntu-latest):
So when you informed ubuntu-latest on your workflow, you asked Github to provide a runner to execute all the steps contained in your job implementation (it is not related to the server you wish to deploy, but to the pipeline that will perform the deploy operation (in your case)).
Related
I am trying to set up a Node app to deploy to Digital Ocean after pushing to a Github repo. I am using Github actions and have followed this tutorial but have hit a snag at step 5. I get the following error when I try to push to the repo.
! [remote rejected] master -> master (refusing to allow an OAuth App to create or update workflow `.github/workflows/main.yaml` without `workflow` scope)
error: failed to push some refs to 'https://github.com/IT-ACA/hello-node-do.git'
I have tried everything I can find, including this SO post, but nothing works. I have a .yaml file in my project, which I can't see anything immediately wrong with, that currently looks like this.
name: CI
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the master branch
push:
branches: [ master ]
pull_request:
branches: [ master ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
name: Deploy NodeJS App
uses: jjst/action-digitalocean-deploy-app#v2
with:
token: ${{ secrets.GH_PERSONAL_ACCESS_TOKEN }}
host: ${{ secrets.SSH_HOST }}
key: ${{ secrets.SSH_KEY }}
username: ${{ secrets.SSH_USER }}
script: |
cd hello-node-do
git clone https://github.com/IT-ACA/hello-node-do.git
echo 'Deploy successful to Digital Ocean..'
Note that I have a different value for uses in the yaml code above which comes from this page and is what I began my DigitalOcean deployment journey with. But, I have also tried the one from the tutorial linked above without any luck.
I think the secrets are all correctly in place and that I have done everything necessary on the DigitalOcean side but it still throws this error. This is the very first time I have tried implementing a CD/CI pipeline and I have spent hours troubleshooting it now. Running out of ideas and would appreciate any help getting over this frustrating hurdle. Thanks in advance!
I have a GitHub action that contains some npm and gulp commands and finally runs a Powershell file. I want to publish this GitHub action on the marketplace so that my team can use it. I can't find a solution to this problem anywhere. I checked the publish Github actions docs, there is no related document.
How do I invoke this action externally?
For instance, How do I convert this simple action so that it can be published to the marketplace?
Sample yml code
# This is a basic workflow to help you get started with Actions
name: CI
on:
push:
branches: [ master ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: windows-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
- uses: actions/checkout#v2
- name: Use Node.js
uses: actions/setup-node#v1
with:
node-version: '10.x'
- name: Install dependencies
run: |
npm install
Thank you
The yaml you've posted here is a workflow, not an action. An action is the code behind the things like uses: actions/checkout#v2 (usually JavaScript, can be Dockerized too). If you're only writing YAML, you're just writing a workflow that invokes actions.
If you want to make your own action, check out the docs.
I have this proof-of-concept (just displaying the relevant parts) in a GitLab CI pipeline:
deploy:development:
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == "master"
script: do_deploy
variables:
ANSIBLE_INVENTORY: development
deploy:test:
stage: deploy
environment:
name: test
url: https://env.url.tld
rules:
- if: $CI_COMMIT_BRANCH == "master"
when: manual
script: do_deploy
variables:
ANSIBLE_INVENTORY: test
I would like to disable/deprecate the previous deploy:test jobs when a new one is created. Basically, the deploy:test job should only be enabled for the current/latest pipeline, hence preventing an old build to take over a recent one.
I'm not saying that it should happens instantaneously; if it's running, is fine to let if finish, but if it failed and a new one is created, the old one (failed) should be disabled also. Same for the current one, if it ran successfully, it should be disabled — this is an optimal state.
Is there a configuration setting that will let me do that? I have checked Auto-cancel redundant, pending pipelines and Skip outdated deployment jobs in Settings > CI/CD > General pipelines, but still the job doesn't get disabled on previous pipelines.
I have checked Auto-cancel redundant, pending pipelines and Skip outdated deployment jobs in Settings > CI/CD > General pipelines, but still the job doesn't get disabled on previous pipelines.
It should work better with GitLab 15.5 (October 2022):
Prevent outdated deployment jobs
Previously, some outdated jobs could be manually started or retried even when Skip outdated deployment jobs is enabled.
We have updated the logic for this setting to check the deployment status when a job starts.
The job does not execute if the deployment job is outdated due to a more recent deployment.
This check ensures that outdated deployment jobs are not accidentally started, overwriting more recent code changes in production.
See Documentation and Issue.
Did you try adding the "interruptible" tag?
It seems like you have to add interruptible: true to your yaml.
For example:
deploy:development:
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == "master"
script: do_deploy
interruptible: true
variables:
ANSIBLE_INVENTORY: development
Ref: https://gitlab.com/gitlab-org/gitlab/-/issues/32022
currently I'm trying to understand the Gitlab-CI multi-project-pipeline.
I want to achieve to run a pipeline if another pipeline has finshed.
Example:
I have one project nginx saved in namespace baseimages which contains some configuration like fast-cgi-params. The ci-file looks like this:
stages:
- release
- notify
variables:
DOCKER_HOST: "tcp://localhost:2375"
DOCKER_REGISTRY: "registry.mydomain.de"
SERVICE_NAME: "nginx"
DOCKER_DRIVER: "overlay2"
release:
stage: release
image: docker:git
services:
- docker:dind
script:
- docker build -t $SERVICE_NAME:latest .
- docker tag $SERVICE_NAME:latest $DOCKER_REGISTRY/$SERVICE_NAME:latest
- docker push $DOCKER_REGISTRY/$SERVICE_NAME:latest
only:
- master
notify:
stage: notify
image: appropriate/curl:latest
script:
- curl -X POST -F token=$CI_JOB_TOKEN -F ref=master https://gitlab.mydomain.de/api/v4/projects/1/trigger/pipeline
only:
- master
Now I want to have multiple projects to rely on this image and let them rebuild if my baseimage changes e.g. new nginx version.
baseimage
|
---------------------------
| | |
project1 project2 project3
If I add a trigger to the other project and insert the generated token at $GITLAB_CI_TOKEN the foreign pipeline starts but there is no combined graph as shown in the documentation (https://docs.gitlab.com/ee/ci/multi_project_pipelines.html)
How is it possible to show the full pipeline graph?
Do I have to add every project which relies on my baseimage to the CI-File of the baseimage or is it possible to subscribe the baseimage-pipline in each project?
The Multi-project pipelines is a paid for feature introduced in GitLab Premium 9.3, and can only be accessed using GitLab's Premium or Silver models.
A way to see this is to the right of the document title:
Well after some more digging into the documentation I found a little sentence which states that Gitlab CE provides features marked as Core-Feature.
We have 50+ Gitlab packages where this is needed. What we used to do was push a commit to a downstream package, wait for the CI to finish, then push another commit to the upstream package, wait for the CI to finish, etc. This was very time consuming.
The other thing you can do is manually trigger builds and you can manually determine the order.
If none of this works for you or you want a better way, I built a tool to help do this called Gitlab Pipes. I used it internally for many months and realized that people need something like this, so I did the work to make it public.
Basically it listens to Gitlab notifications and when it sees a commit to a package, it reads the .gitlab-pipes.yml file to determine that projects dependencies. It will be able to construct a dependency graph of your projects and build the consumer packages on downstream commits.
The documentation is here, it sort of tells you how it works. And then the primary app website is here.
If you click the versions history ... from multi_project_pipelines it reveals.
Made available in all tiers in GitLab 12.8.
Multi-project pipeline visualizations as of 13.10-pre is marked as premium however in my ee version the visualizations for down/upstream links are functional.
So reference Triggering a downstream pipeline using a bridge job
Before GitLab 11.8, it was necessary to implement a pipeline job that was responsible for making the API request to trigger a pipeline in a different project.
In GitLab 11.8, GitLab provides a new CI/CD configuration syntax to make this task easier, and avoid needing GitLab Runner for triggering cross-project pipelines. The following illustrates configuring a bridge job:
rspec:
stage: test
script: bundle exec rspec
staging:
variables:
ENVIRONMENT: staging
stage: deploy
trigger: my/deployment
We are using Gitlab CE and Gitlab Runner for our CI/CD on our Stage Servers. We got a branch for lets say dev1 where we need to do different tasks for different changes.
E.g. for frontend stuff we need a compiler to start and for backend we need to run php-unit.
Can I decide in the push what kind of Pipeline I want to start? I saw tags but they are different in git (for versioning) and gitlab (for runners) I suppose.
Is there a best practive for that use case or do I have to use 2 different branches?
You can define two manual tasks for dev1 branch, and decide on your own which task to invoke.
run-php-unit:
stage: build
script:
- echo "Running php unit"
when: manual
only: dev1
start-compiler:
stage: build
script:
- echo "Starting compiler"
when: manual
only: dev1