I, too, would like to have MQL functionality akin to SQL's "LIKE".  How do Mingle users live without this?

You can autowire the "Environment" to your fixture and get your os and enviroment level properties from it. For example, if you have a Context (or Fixture), naming "Login", you can do like below to get environmental properties like os.arch, os.name etc:

public class Login {   
    @Autowired
    org.springframework.core.env.Environment env;
    
    public void setUp() throws Exception {
         System.out.println(env.getProperty("os.arch"));
     }

    public void tearDown() throws Exception {
    }

}

 

If you are looking to get the properties declared in twist.properties, then you have to do a little bit more. Following is an approach where we have a custom PropertyPlaceholderConfigurer which binds the properties at the context xml level, as well provide a way to read the same properties when it is referred elsewhere.

** Declare your Custom property placeholder first like the class below (e.g. com.test.CustomPropertyPlaceHolderConfigurer)

------------------------------------------------------------------------------------------------------------------------------------

package com.test;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Properties;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.beans.factory.config.PropertyPlaceholderConfigurer;

public class CustomPropertyPlaceHolderConfigurer extends
        PropertyPlaceholderConfigurer {

    private int sysPropMode;
    private Map<String, String> propertiesMap;

    @Override
    public void setSystemPropertiesMode(int systemPropertiesMode) {
        super.setSystemPropertiesMode(systemPropertiesMode);
        this.sysPropMode = systemPropertiesMode;
    }
    
    @Override
    protected void processProperties(
            ConfigurableListableBeanFactory beanFactoryToProcess,
            Properties props) throws BeansException {
        super.processProperties(beanFactoryToProcess, props);
        propertiesMap = new HashMap<String, String>();
        for (Object key : props.keySet()) {
            String keyStr = key.toString();
            String valueStr = resolvePlaceholder(keyStr, props, sysPropMode);
            propertiesMap.put(keyStr, valueStr);
        }
    }
    
    public String getPropertyValue(String name) {
        return propertiesMap.get(name);
    }
    
    public List<String> getPropertyNames() {
        ArrayList<String> propertyNames = new ArrayList<String>();
        for (Object key : propertiesMap.keySet()) {
            propertyNames.add(key.toString());
        }
        return propertyNames;
    }
}

---------------------------------------------------------------------------------------------------

** change the applicationContext-suite.xml file to refer to your custom property placeholder like below (note, only thing that i have changed is the classname)

<bean class="com.test.CustomPropertyPlaceHolderConfigurer">
    <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>
    <property name="locations">
      <value>classpath:twist.properties</value>
    </property>
</bean>

---------------------------------------------------------------------------------------------------

** now you can autowire the custom placeholder to your context or fixture. e.g. in your Login class

public class Login {   
    @Autowired
   com.test.CustomPropertyPlaceHolderConfigurer propertyConfigurer;
    
    public void setUp() throws Exception {

        System.out.println(propertyConfigurer.getPropertyValue("twist.generate_local_report"));
         for (String property : propertyConfigurer.getPropertyNames()) {
            System.out.println(String.format("Property %s=%s", property, propertyConfigurer.getPropertyValue(property)));
        }
     }

    public void tearDown() throws Exception {
    }

}

---------------------------------------------------------------------------------------------------

 

Hope this works for you.

regards

When is the future release?  Where's the Mingle on Mingle page so I can check the status of this feature?  This is pretty sad that such a basic reporting feature is not yet implemented.

Hi Russell,

Answer to your first few queries:

Parameters are not really meant to be dynamic. They are a part of your configuration and can be used to customize/simplify the pipeline configuration.

GO_PIPELINE_NAME and GO_PIPELINE_COUNTER are environment variables and cannot be used as parameters.

   " So how would I tell <fetchartifact> the dynamically generated name of this artifact?  Is this even currently possible?"

No, this is not currently possible. 

Just as a suggestion, when you define a fetchArtifact task to fetch artifact from PipelineA-StageA-JobA, then it will always pick it up from the the latest run of PipelineA-StageA-JobA. So you could fetch the whole folder which cotains your artifact too.

thanks for the ideas, I think two trees is more complex for my simple situation which generally has one week of overlap and minimal work on the previous release.