I'm new to GitLab ci and I was curious if something could be done inside the .gitlab-ci.yml. For our project we want two different things to happen dependent on two actions. For instance, when a new file is added to the master branch we want Job1 to run. However, when a file is updated in the master branch we would like Job2 to run instead.
Based on reading through Gitlab's documentation on ci/cd it looks like you could do this by using variables and rules.
So, would this be possible inside the yml file or would you have to go about it another way?
Thank you for your replies.
As you might have already noticed there is a rule named changes which you could try out. If that's not sufficient you still could execute something like git diff-tree inside a container and then decide what to do.
I doubt that you can do it directly with a conditional over a file because the commit push (which is the action that triggers the pipeline containing the job, ultimately) could contain several files.
Having said that, you have a bunch of predefined variables with information about the commit itself, so maybe you can agree with the team on a commit description template for when they add a file and another one for the case of the update. Then you can easily use rules to determine which job has to run. For this particular case, you will be using the CI_COMMIT_DESCRIPTION variable.
You can also base your condition on a tag, but I think that it will make the repository too dirty.
I know that it is easy to forget the rule, but still, it is an easy workaround.
Related
I have this repository that i forked from another one, and now i need to make a pull request to it, but it says that: "There isn’t anything to compare.", and my commits are not showing:
https://github.com/amorimll/desafio-sharenergy-2023-01
Any help is appreciated, really need this for today.
This is showing in the git rebase:
Short answer
will be checkout to your main branch get the lastest code, then go back to your current working on branch and do git rebase [currentBranchName] main
Explain
so when your create a branch from another branch, is like your created a snapshot code from that branch at that moment. ideally the branch you copied form should prevent make any more changes if possible, until you done working in the new branch and create the PR and done marge it.
what rebase command will do is in case the origin branch had changes, it will pull the latest code form that branch into your working branch first, then to applied any changes you was made for your current working branch. Usually this process will need have some conflict need to fix, if they changed the same file.
Hope this is help you understand :)
I'm currently working on a code refactor project for terraform, we want to take all of our old terraform and restructure it so it would be more "developer friendly".
we don't want to do this all at once so we want to move the resources to the new code structure in small batches.
the old code is deployed automatically every day by a pipeline and we want to keep it that way at least until we move everything and we can't really change the original code.
is there a way to move a resource to be controlled by the new code while keeping the old deployment workflow without changing the old code at all? while running the old terraform code after having changed it with the new one we get a message that something changed outside of terraform and it tries to change it back, is there any way to ignore a resource if it has been changed outside of terraform but without touching the old code? something like --ignore-drift or similar?
One option to consider is to use targeting: -target argument to terraform apply. Not sure if you count it as "not modifying the code".
Modify your daily pipeline - i.e. the call(s) to terraform apply.
You could start with a -target expression (or several of them) which cover the whole configuration and gradually edit the expression to include less and less resources.
I've a list of features files and the list of the related step definitions. Every feature file refers to some specific functionality of the website.
According to some environment variables defined in package.json and representing the theme of the website, I might need to skip entirely some of the feature files (and obviously their step definition), due to missing feature for some specific theme.
To give some code examples:
"test:cy:run:daylight": "PORT=9000 CYPRESS_THEME=daylight cypress run",
"test:cy:run:darkness": "PORT=9001 CYPRESS_THEME=darkness cypress run",
feature files list:
daylight.feature
afternoon.feature
evening.feature
night.feature
with the relative definitions:
daylight.spec.js
afternoon.spec.js
evening.spec.js
night.spec.js
So in case of CYPRESS_THEME=darkness I would like to skip entirely from my testing process the features evening.feature and night.feature
How to do that? Ideas?
This example is with fake data, my real scenarios includes many more features and themes, so unluckily splitting test in different folders or using Cypress tag is not an efficient option.
Another not efficient idea I am thinking of is to put conditionals in every step definition Given, When and Then with the help of the detection of the Cypress.env('THEME') but obviously I would prefer not to follow this approach.
Anything else? Thanks
The correct answer would be to tag the tests and run only specific tags... if such a feature existed. I believe #mosaad is wrong on his second point; the --tag command line parameter merely adds meta data to the run from what I understand. It doesn't restrict which spec files get run.
If I were you I'd just try to get creative with your folder structure. Alternatively you can implement this person's workaround, which seems a bit heavy to me but probably gets the job done.
You can split tests into 2 folders and run only the files in this folder
cypress run --spec "cypress/integration/daylight/**/*"
Or you can use tags and run tests with the correct tag
cypress run --record --tag "daylight"
I'm new to Gitlab API, I know how to create a tag on a specific branch, let's say I have several branches on my repository, and I created several tags on each branch. Now I want get all the tags on a specific branch with GitLabAPI. I've read the Branchs API and Tags API docs carefully, however was unable to find an answer to my question. Please help me out.
I am unsure what you're trying to accomplish as you literally described your problem with one short sentence, so it will be more of a guess.
If what you want to do is to create GitLab tag for a specific commit for a specific branch, you simply do that as you can define branch when creating it. Will not post description of how it should be done as there is documentation.
With GitLabAPI(as you wanted based on you problem description) follow this link:
How to with GitLabAPI
And instead of Release tag just make same steps for any other tag. For tagging from console you should follow this one:
How to with git
If you're looking for a way to find specific tag with GitLabAPI just go that way:
Repository->Tags->Filter by tag name
Tags are unique across the whole repository.
For doing checkout from console:
git checkout <tag>
Your consternation, I believe, comes from misunderstanding the idea of tags. It's kind of a snapshot of repository at specific point, might be for release, may be for backup purposes, does not matter, it's up to you. Important part is that no matter where you will place it, it has to be unique in scope of a whole repository not just a branch you place it. There is no way to create two same tags on two different branches, git won't let you. Read info from links and everything should be clear.
If my answer is not what you were looking for, expand your question to get more proper and accurate one.
What I want to do is to allow all developers to create their own feature branches, merge them, etc. but a special branch "Release" should be writable only by one single engineer (or a group). What I tried is:
[acl.allow.branches]
release = #release-manager
[acl.deny.branches]
release = *
I also want the release manager to be the only one who can add tags in the repo. How to do that?
I found out that what I wanted is un-doable using the current implementation of MercurialACL, I decided to hack it and support change the way is work to let my usecase work. Also my fork allows you to use globing in branch names like:
release-* = #release-manager
this will work for any branch the starts with release-, like "release-1.0"
You can find the code here https://bitbucket.org/cloud9ers/mercurialacl/