CircleCi config - duplicate workflow run with delay and env var - circleci

May my approach here is completely wrong. I need to figure out how to run workflow_one twice with the only difference being that the second time I run it I want to include artificial delay before executing the jobs and have a specific env var set to true and accessible to all jobs, say MY_FEATURE_ENABLED=true.
I thought I can achieve this by duplicating the workflow_one and figuring out how to pass a parameter so that the job_one and job_two can have a conditional step to set this MY_FEATURE_ENABLED=true and just perform sleep 180 for the delay.
workflows:
version: 2
workflow_one:
jobs:
- job_one:
- job_two:
context: some-secrets
workflow_one_clone:
jobs:
- job_one: # pass parameter
- job_two: # pass parameter
context: some-secrets
If this approach would work - how can I set and pass this parameter for the workflow_one_clone 's jobs?
Otherwise if there is a better way to do this - I'd love to learn it!

Related

Is there a way to emulate read-write lock for Jenkins Pipeline Jobs?

I have some unset number of jobs that use resource A in a "reading" manner.
All these jobs can run concurrently just fine.
I've also have a job that "writes" to A. This job cannot run in parallel with "reader" jobs.
How would I solve this problem for Jenkins Pipelines?
Is there a way to implement simple "read-write lock"?
It looks like lock() can only be used to implement exclusive lock.
There is a way, create multiple resources with label for example 'mylabel' (as many as many readers you have). I believe the quantity parameter is poorly documented.
Reader lock
lock(label: 'mylabel', quantity: 1) {
...
Writer lock - no quantity - so that's the default which is require all
lock(label: 'mylabel') {
...

is it good to use global variables in specs?

is it good to use global variables in specs?
I want to use this var in my tests. And define it in spec_helper.rb
$now = DateTime.parse('2020-01-01 00:00:01 -0500')
Is this a good idea or not? and why?
Global variables are discouraged, in RSpec, and in general. Here's why:
Modifying a global variable anywhere affects code everywhere.
So, if a test ever modified the $now variable, all subsequent tests would be affected by the modification. This could lead to some very hard to debug test failures. Hard to debug, because the test would be correct. But, the value of the global would not. So, you could not find the bug in the tests by simple inspection. You'd have to debug it at runtime.
Automated tests need to be independent of each other. This is why RSpec has the lazily executed let statement. let allows you to define a variable within the context of a single example. Here's what the RSpec docs say:
Use let to define a memoized helper method. The value will be cached across
multiple calls in the same example but not across examples.
What this means is that if you define now like this:
let(:now) { DateTime.parse('2020-01-01 00:00:01 -0500') }
The value is guaranteed to be exactly what you say it is in every single test. Because the value is memoized on a per example basis, one test can never affect the value that another test receives when executing.
If you're still not convinced, I would recommend using a global constant over a global variable. At least then, Ruby would warn you if you tried to change the value.
It's a bad idea. Actually, you should avoid using global variables anywhere in your code.
You can use before block to set any variable to need to use along with your tests examples.
Example:
describe Thing do
before(:each) do
#now = DateTime.parse('2020-01-01 00:00:01 -0500')
end
describe "initialized in before(:each)" do
it "example 1" do
// here #now is available
end
it "example 2" do
// here #now is also available
end
end
end

Storing a Database Connection String in AWS Fargate Container

Right now I have a container for an API that I am looking to push to an AWS Fargate instance that has a connection string for a DB on a privately hosted server. For testing this has been stored in a string in my Golang program, but I don't really want to push that even with the program already compiled.
I have looked into using the GO AWS SDK for the SecretsManager, but I am not sure if that is the best way to go, or if it will even work like I am hoping it will. What is the best way to handle this?
Hardcoding things into the program is obviously never the best choice, so I share your pain and the need for something better, that could be:
Define the connection string into an environment variable. This solution does not keep the information "secret", so if it's something that you would not like to have it readable in any way, try with the next
Define the connection string into Secrets Manager and refer to in the environment variable definition
Doing this with CloudFormation we will have in the first case:
...
Environment:
-
Name: CONNECTION_STRING
Value: 'YOUR VALUE'
...
While in the second case we would have:
...
Environment:
-
Name: CONNECTION_STRING
Value: '{{resolve:secretsmanager:MySecret:SecretString:connection_string}}'
...

jbehave - How to execute code before each example of a scenario

When using Serenity with JBehave, my step definition adds information provided through #Given and #When into an internal state class, which is validated in #Then methods.
The state class needs to be reinitialized for each test, that is before each scenario without example and before each example of a scenario with examples.
How can I achieve that?
I found a JIRA ticket requesting #BeforeExample (which would solve my problem) at http://jbehave.github.io/Old_JBehave_Issues/548/. However, using #BeforeScenario clears only before each scenario, but not before each example.
Clearing state in each #Given would not work in the cases where a scenario has multiple #Givens (using Given... And....).
#BeforeScenario does not work (is ignored for scenarios with examples alltogether).
#BeforeScenario(uponType = ScenarioType.ANY) does work, which I found not working before posting this question, but was apparently caused by another reason.
Either way, the method must be public.
You might try to reset scenario-state using JBehave's 'Before' LifeCycle:
Narrative:
...
Lifecycle:
Before:
Given a step that is executed before each scenario
Some additional Lifecycle options:
Lifecycle:
After:
Outcome: ANY
Given a step that is executed after each scenario regardless of outcome
Outcome: SUCCESS
Given a step that is executed after each successful scenario
Outcome: FAILURE
Given a step that is executed after each failed scenario
Source: JBehave Story Syntax

How to set the order sentestkit-test runs?

I am using SenTestKit to test an iOS app. I've split tests into methods which run
For example:
In
#interface simpleGameTests : SenTestCase
With tests:
- (void)testFindingFacebookFriends
- (void)testRegisterUsernameFromForm
- (void)testStartGame
It seems kind of random which of the tests that run first, second and third. Is it possible in Xcode to set the order which the tests run?
No. You should write your tests as isolated cases that can be run no independent of each other, no matter the order.
Yes, although the accepted answer is idealistically true and your test cases should indeed be isolated you can set the order in actuality you can control the order and sometimes it is preferable to do so. They are executed in alphabetical order, so testACreateAccount will be executed before testBLoginToAccount. I use this to generate a password in setUp routine then use that in testACreateAccount to setup the account and testBLoginToAccount to test account login using the created one. In this way the test is full and complete (and also no longer strictly a unit test) but it is an invaluable test for my code.

Resources