I have two projects on gitlab : a frontend (angular) and a module backend (spring). So I would like to use a pipeline to run tests on the frontend after backend was tested and builded . For example, I'd like run tests and build backend modules when it succeeds I'd like run the frontend tests which call the api back before I deploy it as below :
Frontend pipeline .gitlab-ci.yml : stage back : tests => build the backend then stage front : run the tests on api back => build the frontend
How I can do this, please ?
You could use Gitlabs Multi-Project Pipelines Feature: https://docs.gitlab.com/ee/ci/multi_project_pipelines.html#multi-project-pipelines
For example you can add a build-backend job to your frontend gitlab-ci.yml. This job starts the pipeline in the Start/backend Repository and waits for it to end (configured with strategy: depend). In the gitlab-ci.yml of the backend project, you can build and test the backend modules and after this pipeline finishes, the next jobs in the frontend pipeline are executed.
build-backend:
stage: build-backend
trigger:
project: Start/backend
strategy: depend
You can use the GitLab Pipelines API to create a new pipeline in the frontend project.
This means you would have two .gitlab-ci.yml files -- one in the backend project, and one in the frontend project.
See also: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html (you'll need an access token to auth with the GitLab API. You can so via Oauth2 or by using a personal access token, which you might find easier to start with).
Related
I have my e2e tests (using WebDriverIO) running on Gitlab Pipeline. I already setup a hook to connect to Microsoft Teams, so whenever the tests fail, I receive this message in Teams:
So, then I click on the Pipeline ID and check the specs to see which tests are failed and so on.
My question: is it possible (and how) to export also the specs into this message, for example, I would like to have the following specs as part of the message to Teams:
I'm trying to add the sonarqube badge to my Gitlab repository.
I've read some answers that talk about this issue for the private project, but it's not the case for me:
Sonarqube quality badges on gitlab
My project is public:
but still, I get 401 on the badge API endpoint:
Request URL: https://{my.sonarqube.domain}/api/project_badges/measure?project={project-key}&metric=alert_status
Request Method: GET
Status Code: 401
Just to clarify more:
The API endpoint is throwing 401 unless I send the auth token with the request.
But I can't set a basic auth on the Gitlab badge section, Can I?
Sonarqube Version: 8.9 (build 43852)
A workaround can be achieved waiting for the sonarqube team to solve their authentication problem:
We need to retrieve svg from sonarqube using curl and save them as artifacts
Then we can create custom badge in the gitlab settings.
Ie :
badges-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
script:
- 'curl -u ${sonarqube_token}: "https://example.sonarqube.com/api/project_badges/measure?project=Test&metric=coverage" > sqcoverage.svg'
artifacts:
paths:
- sqcoverage.svg
Settings in gitlab settings :
Badge image URL
https://example.gitlab.com/%{project_path}/-/jobs/artifacts/%{default_branch}/raw/sqcoverage.svg?job=badges-job
I've asked the same question at SonarCommunity site.:
https://community.sonarsource.com/t/public-project-badge-to-gitlab-401/47766
Thanks for Eng. Sylvain Combe for his answer.
Apparently, This can't be done without authentication, the only option available now is disabling sonar.forceAuthentication attribute in your sonar configuration, which will make your sonar accessible by everyone.
I am trying to publish Gatsbyjs by Azure Static web app.
I have a plugin (gatsby-source-contentful).
I need to pass variables like:
{
resolve: `gatsby-source-contentful`,
options: {
spaceId: process.env.CONTENTFUL_SPACE_ID,
accessToken: process.env.CONTENTFUL_ACCESS_TOKEN,
},
},
Error:
Running 'npm run build'...
> gatsby-starter-default#0.1.0 build /github/workspace
> gatsby build
success open and validate gatsby-configs - 0.021s
error Invalid plugin options for "gatsby-source-contentful":
- "accessToken" is required
- "spaceId" is required
not finished load plugins - 0.905s
Where can I pass this?
Thanks.
For Azure Static Web Apps there is two ways to set environment variables one for front-end and one for back-end scenarios.
Since you are using Gatsby, I guess its safe to assume you are building your front-end. For that you will need to add the environment variables on your build configuration (azure-static-web-apps-.yml).
Like so:
env: # Add environment variables here
CONTENTFUL_SPACE_ID: <your-id>
Here is the link for that in documenation.
Not to be confused with this one which is used for defining backend environment variables.
They are called environment variables. They are intended to store sensitive data such as tokens, identifiers, etc, and they shouldn't be pushed in your repository, so you should ignore them (in your .gitignore file).
By default, Gatsby creates 2 environments without noticing you, one for each compilation method:
gatsby develop: uses .env.development
gatsby build: uses .env.production
Note: you can change this behavior if needed to add your own environments using NODE_ENV custom commands.
So, to pass your data to your gatsby-config.js you just need to create two files (.env.development and .env.production) at the root of your project. Then, add the following snippet at the top of your gatsby-config.js:
require("dotenv").config({
path: `.env.${process.env.NODE_ENV}`,
})
Note: dotenv is already a dependency of Gatsby so you don't need to install it again
This will tell Gatsby where to take the environment variables.
You just remain to populate both environment files. Look for the credentials in Contentful and add them in the files using the sane naming than you've set in your gatsby-config.js:
CONTENTFUL_SPACE_ID=123456789
CONTENTFUL_ACCESS_TOKEN=123456789
Keep also in mind that when dealing with Azure, Netlify, AWS, or similar CI/CD tools, you'll need to provide to the server the same environment files to avoid a code-breaking when pushing the changes.
I would like to use Parent\Child pipilens https://docs.gitlab.com/ee/ci/parent_child_pipelines.html in this way.
I have this source structure:
- backend
--- .gitlab-ci.yml
--- src
- frontend
--- .gitlab-ci.yml
--- src
-.gitlab-ci.yml
I want to trigger backend or frontend .gitlab-ci.yml based on the path where new commit happens: if it happend on frontend, only frontend.gitlab-ci.yml should be used for build\publish.
Is it possible?
You can specify to execute different pipelines based on where the changes in the code occurred using the only: changes configuration documented here.
You can therefor specify to execute a pipeline frontend only if changes happen within the frontend folder (analog for `backend).
You can use the include: local feature (documented here) to include the frontend/.gitlab-ci.yml-file within the pipeline for the frontend that is defined in the root .gitlab-ci.yml.
For examples on how to exactly configure the pipeline so that it triggers a configuration provided in a local file, please see here.
Parent-child pipelines also support the only: changes configuration as documented here.
ERROR: (gcloud.app.deploy) Error Response: [9] Cloud build 6axxx...xxx9b status: FAILURE.
I'm trying to understand if I can use a NodeJS / Express server with Google Cloud App Engine, Standard Mode. My application started out from an Express-Generator framework. There is a single page app, and some function calls back to server via custom routes. Nothing terribly crazy.
I set up repo, and $ git clone https://gitlab.com/my_repo into the GCloud shell. Test, test and retest using the sandbox (local development server.) Test url is of the form: https://8080-dot-xxxxxx-dot-devshell.appspot.com Yipee.
Next step is hard deploy: I start with $ gcloud app create followed by $ gcloud app deploy (had to make a side trip to ensure correct authorization and billing stuff is whole, etc...) . Website / server totally works as intended. URL is of the form https://my-custom-XYZ-website.appspot.com/ Works great.
I can check the version at the Google Cloud Platform -- App Engine -- Version console The output there shows me:
Version: 20181120t103136
Status: Deployed
Traffic Allocation: 100%
Instances: 1
Runtime: Node10
Environment: Standard
Size: 748.8 KB
Deployed: (Date/Time by me)
So that's the background. The problem is now I can no longer update the content. I can easily push code to the terminal interface, but the command $ gcloud app deploy fails for any sort of update / new version. Sigh.
Log related info -- Build steps:
Fetcher = successful
Builder = status, Step Failed
Builder Arguments
--name=us.gcr.io/my-custom-XYZ-website/app-engine-tmp/app/ttl-2h:12xxxxxxa5a0 --directory=/workspace --destination=/srv --cache-repository=us.gcr.io/my-custom-XYZ-website/app-engine-tmp/build-cache/ttl-7d --cache --base=gcr.io/gae
runtimes/nodejs10:nodejs10_10_13_0_20181111_RC00
Directory /workspace/
"builder": Permission denied for "d71xxxxxxxxxxxxxxxxxx88b5" from request "/v2/my-custom-XYZ-website/app-engine-tmp/build-cache/ttl-7d/node-cache/manifests/d71xxxxxxxxxxxxxxxxxx88b5". : None
app.yaml
# [START runtime]
runtime: nodejs10
# [END runtime]
handlers:
- url: /images
static_dir: public/images
- url: /javascript
static_dir: public/javascript
- url: /red-canoe
static_dir: public/alt-content
- url: /stylesheets
static_dir: public/stylesheets
- url: /.*
secure: always
redirect_http_response_code: 301
script: auto
Any idea on how to identify and correct what's wrong here?
Note: I did create another simple test product in node.js, and I can easily update the versions there. That test product had only a simple app.js with a simple Hello World response. Version #2 had Hello There, World (okay, so yeah, not the worlds most robust test...). But the version update, via $ gcloud app deploy worked just fine there. I did note the version size on the Hello World app was around 245kb or so.
So, after a whole lot of testing I think I figured out what is happening here.
The node.js application actually utilizes three different Google related components / tools.
Google Firebase Authentication
Google Sheets API, V4
Google App Engine (Deployment)
When I'm created those components, the system prompts me to either create a new project or utilize an existing project. I chose the exact same project for all three tools. I believe the fact that these were all tied together messed up the ability to perform updates to Google App Engine vcloud app deploy
The fix was to delete that three combo project, and create three separate projects
MyProject_Sheets
MyProject_Firebase_Auth
MyProject_AppEngineDeploy
This works reliably. All done.
And for anybody who may be interested in the Firebase / Sheets API stuff I did here, check out this link. I built an online phone directory, protected by login via mobile phone, with contact data stored on a private Google sheet.