I have in my yml include to a certain yml can I add ignore_erors like:
include: ../test.tml
ignore_errors: yes
or only in the playbook I included itself
thanks.
Playbook keywords can be applied to 4 objects: a play, role, block, task. ignore_errors can be applied to all of them.
Correct syntax
In your example, include is a task. The correct syntax is
- include: ../test.yml
ignore_errors: yes
Include is deprecated
Quoting from include - Include a play or task list
The include action was too confusing, dealing with both plays and tasks, being both dynamic and static. This module will be removed in version 2.8. As alternatives use include_tasks, import_playbook, import_tasks.
Related
My pipeline has two different contexts, per se. If a developer is running on a branch other than main, a job called scan_sandbox is created on the pipeline of the merge request to scan the Dockerfile that the developer is working on currently.
When the branch is merged into main, a scan_production job is created, implying that the image is going to be pushed to the registry and later used in production environment.
My problem is to deal with this variable stage name, either scan_sandbox or scan_production with the needs statement, in order to fetch and publish the scan results. I've tried...
needs: ["scan_production", "scan_sandbox"]
But it returns an error, since both stages aren't going to be declared in different contexts. Also tried...
needs: ["container_scan"]
Which is the name of the stage where both scans will run, but GitLab CI also doesn't interpret it this way.
Anyone has any ideas?
Here is an image of the problem:
You can specify a dependency to be optional in Gitlab yaml. In case if it's optional, Gitlab won't fail if the stage was not executed. It is specifically added to handle the stages with rules, only, or except conditions.
So you can specify
needs:
- job: scan_sandbox
optional: true
- job: scan_production
optional: true
Notes:
This will work for Gitlab version >= 13.9
Doc link: https://docs.gitlab.com/ee/ci/yaml/#needsoptional
Problem Summary:
My goal is to add a rules clause to configure a Gitlab CI job to run if an environment variable is set, or if manual action is performed. Unfortunately, the step currently makes use of only and except clauses so I'll have to also convert them into rules syntax, which I've not fully grasped yet.
Current Job Definition:
deploy:
only:
- branches
except:
refs:
- /flux-.*$/
- master
stage: deploy
when: manual
Required Changes:
I'll be replacing
when: manual
with
rules:
- if: '$CI_ENVIRONMENT_NAME'
- when: manual
Now I'd like to learn how to translate the only/except clauses. I think it'll be completely based on predefined environment variable tests, though I'm unsure which variables are of interest for this translation.
Many thanks for any suggestions or pointers.
As you pointed out using predefined environment variables is the way to go with rules. Many of them can be used to achieve the same thing, it really depends on your needs (For example: $CI_COMMIT_REF_NAME vs $CI_COMMIT_REF_SLUG vs $CI_COMMIT_BRANCH).
My goal is to add a rules clause to configure a Gitlab CI job to run if an environment variable is set, or if manual action is performed.
Just to be sure to understand what you mean by that:
If $CI_ENVIRONMENT_NAME then always run the deploy job, otherwise if the branch is not master and doesn't match /flux-.*$/, then allow the deploy job to be triggered manually.
Is that correct?
If yes, one implementation would look like this below. (You can also use || operators to merge the 2 first rules if you want)
deploy:
stage: deploy
rules:
- if: '$CI_COMMIT_REF_NAME == "master"'
when: never
- if: '$CI_COMMIT_REF_NAME =~ /flux-.*$/'
when: never
- if: '$CI_ENVIRONMENT_NAME'
- when: manual
Keep in mind that rules are evaluated in order. Hope that helps.
I couldn't find it online after a little bit of searching, so i'm asking it here. Is there a 'reference' bnf grammar file for yaml file of concourse's pipeline ? As a side project, I'm trying to create an IntelliJ plugin that could do syntax highlight and auto completion for CI/CD Concourse pipelines, and would try to avoid manually retyping all that grammar to minimize error risk and time.
I don't believe there's a "grammar file" - the types are defined in code. For example, the top level pipeline is defined here as:
type Config struct {
Groups GroupConfigs `yaml:"groups" json:"groups" mapstructure:"groups"`
Resources ResourceConfigs `yaml:"resources" json:"resources" mapstructure:"resources"`
ResourceTypes ResourceTypes `yaml:"resource_types" json:"resource_types" mapstructure:"resource_types"`
Jobs JobConfigs `yaml:"jobs" json:"jobs" mapstructure:"jobs"`
}
The atc.Config.Validate() command is also based on code - not an external grammar.
You could probably reason through those source files to determine the structure. It might be possible to generate a jsonschema from the go types and then use that.
I'm looking since several hours for a technic to write a salt state wich requires requirement1 or requirement2.
That's what I would like to do with cmd.run for example:
Run myscript:
cmd.run:
- name: /path/to/myscript
- require:
- pkgs: pkg1|pkg2
- cwd: /
Which means The script my_script will be executed if the state installing the package pkg1 or the state installing the pkg2 is satisfied.
Can this be really be done with salt? If so how?
I know I can make all my checks in my script directly, but I wanted to know if salt requisites could do that cleverly.
Thanks.
Salt states do not support branching if/else/while/ etc. The states file redered into a data which describes static dependency trees. Once rendered, the execution is performed in order.
The only way to do some sort of branching is to use unless/onlyif keywords. But they only work with specific state types and do not accept state ids (AFAIK, they only accept executable shell commands). See: http://docs.saltstack.com/en/latest/ref/states/requisites.html#unless
How to change the environment variable of rails in testing
You could do
Rails.stub(env: ActiveSupport::StringInquirer.new("production"))
Then Rails.env, Rails.development? etc will work as expected.
With RSpec 3 or later you may want to use the new "zero monkeypatching" syntax (as mentioned by #AnkitG in another answer) to avoid deprecation warnings:
allow(Rails).to receive(:env).and_return(ActiveSupport::StringInquirer.new("production"))
I usually define a stub_env method in a spec helper so I don't have to put all that stuff inline in my tests.
An option to consider (as suggested in a comment here) is to instead rely on some more targeted configuration that you can set in your environment files and change in tests.
Rspec 3 onwards you can do
it "should do something specific for production" do
allow(Rails).to receive(:env).and_return(ActiveSupport::StringInquirer.new("production"))
#other assertions
end
Sometimes returning a different environment variable can be a headache (required production environment variables, warning messages, etc).
Depending on your case, as an alternate you may be able to simply return the value you need for your test to think it's in another environment. Such as if you wanted Rails to believe it is in production for code that checks Rails.env.production? you could do something like this:
it "does something specific when in production" do
allow(Rails.env).to receive(:production?).and_return(true)
##other assertions
end
You could do the same for other environments, such as :development?, :staging?, etc. If you don't need the full capacity of returning a full environment, this could be another option.
As a simpler variation on several answers above, this is working for me:
allow(Rails).to receive(:env).and_return('production')
Or, for as I'm doing in shared_examples, pass that in a variable:
allow(Rails).to receive(:env).and_return(target_env)
I suspect this falls short of the ...StringInquirer... solution as your app uses additional methods to inspect the environment (e.g. env.production?, but if you code just asks for Rails.env, this is a lot more readable. YMMV.
If you're using something like rspec, you can stub Rails.env to return a different value for the specific test example you're running:
it "should log something in production" do
Rails.stub(:env).and_return('production')
Rails.logger.should_receive(:warning).with("message")
run_your_code
end