homedepot / flow Goto Github PK

Describe the bug
It appears that the tests are failing for 3.5 due to the ordering of json elements being verified.

Steps To Reproduce
Steps to reproduce the behavior:

1. Run CI/GitHub Actions tests on Master

Expected behavior
Tests should not fail.

Screenshots
N/A

Desktop (please complete the following information):

• OS: Linux
• Flow Version: latest

Additional context
Example test run.

Is your feature request related to a problem? Please describe.
There is a much newer version of the sonar scanning software. The current Flow script utilizes an older jar file that is only compatible with Java 8.

Describe the solution you'd like
Update the Sonar Flow module to utilize an updated version of the sonar scanner software. This should work with multiple versions of the JDK above JDK8.

Describe alternatives you've considered
An alternative to having Flow execute Sonar would be to have Maven or Gradle execute a Sonar scan using the newer Sonar scanners that are utilized by Maven or Gradle build plugins.

Additional context
N/A

Travis builds from forked pull requests will not work as currently designed. This is due to a security restriction and the way travis handles encrypted environment variables for pull-request builds.

The current flow travis pipeline requires encrypted env variables to work properly.

When I first dropped into this project, following the instructions I tried right away to run flow thing -option which, of course, failed. But that's the first thing I hit in the docs. Seeing that this is a Python project I was able to interpret pretty quickly that I needed to python3 setup.py install but not everyone would know this, and I think this project can be very useful to someone who knows no Python at all.

Please add installation instructions to the README.

The README states that the library is MIT licensed, but the LICENSE file itself is the Apache license.

There was a bug introduced in this pull request. e is not defined.

Describe the bug
When a cf push command fails during the flow cf deploy event, an "empty" App is left behind in a "Stopped" state. This behavior is due to the cf push command not cleaning up after itself. After an unsuccessful Deploy stage in a pipeline, the most logical thing to do is to check the logs and correct why the Deploy stage failed, like a buildpack didn't download or a Server wasn't bound properly. What engineers typically do not do is check cf apps to notice that their App was created in a Stopped state in preparation for Service binding, buildpack download, or bits push. Upon a second execution of the Deploy stage, the Stopped current-version App is identified in a step that records all Stopped apps. After a successful cf push Flow will cf delete these Stopped apps. This also deletes the just-deployed current-version App from the Foundation. The Flow step will finish and report a success. There are no further checks to ensure that the just-deployed current-version App is healthy.

To Reproduce
Steps to reproduce the behavior:

1. Run flow cf deploy... and experience a failure of cf push, like including a non-existent Server in the manifest.
2. Repair the cause of the errored cf push execution.
3. Run the same flow cf deploy... command again
4. Assuming successful exit 0 from flow, App will not exist.
5. Check logs to see that _start_stop_delete_app() deleted the App in question

Expected behavior
Flow should:
a) Defensively clean up after itself during a failed cf push event since the cf cli appears to not do so
b) Capture the just-deployed current-version App name and don't delete it when running cleanup code

Screenshots

Desktop (please complete the following information):

• OS: MacOS 11.4
• Flow Version: v0.43.0

Additional context
This bug was discovered after some refactoring of the CloudFoundry module. This previous check checked against whether to delete the App during post-deploy cleanup but the documentation around why this statement exists does not exist.

Within gcappengine.py in the method _gcloud_deploy() this code sets the value of the promote flag passed to gcloud

promote_flag = "--no-promote" if promote is False else ""

This behavior is counter to what is specified in the README

-p PROMOTE, --promote PROMOTE (optional) (etc...). Default is true.

Currently there appears to no way to add the --promote flag to the built gcloud app deploy command

Add automation (travis? docker hub?) to create a docker image containing flow and the basic components needed for flow to function.

Problem:

The flow tool prohibits uploading of multiple artifacts that are created during the build process. Under specific cases uploading multiple artifacts should be allowed.

A single build of a maven/gradle project can produce multiple jar files. It is very common for the source files and the javadocs to be packaged as jar files and uploaded to a maven repository. These jar files include a classifier after the version number. The main application/library jar file does not does not contain a classifier. An example can be found here: Central Repository - Spring Core.

spring-core-5.2.6.RELEASE-javadoc.jar
spring-core-5.2.6.RELEASE-sources.jar
spring-core-5.2.6.RELEASE.jar
...

The classifier can be any arbitrary string.

Proposal:

Update the logic for publishing build artifacts for java projects to include all files that specify a classifier along with the file with no classifier. The list of classifiers that should be published should be added to buildConfig.json at artifactoryConfig.artifact(ory?)Classifiers. The artifact that gets deployed should be the file that contains no classifiers. The check for a single artifact for deployment can still be done, but after the files with classifiers have been filtered out.

Example buildConfig.json:

{
  "projectInfo": {
    "name": "proj1",
    "language": "java",
    "versionStrategy": "...."
  },
  "artifactoryConfig": {
    "artifactoryDomain": "https://.....",
    "artifactoryRepoKey": ".....",
    "artifactoryRepoKeySnapshot": ".....",
    "artifactoryGroup": "com/example/org",
    "artifactClassifiers": ["sources", "javadocs", "stubs"], <<-- Newly added config
    "artifactType": "jar"
  },
....
}

List of files published:

• proj1-{version}.jar
• proj1-{version}-sources.jar
• proj1-{version}-javadocs.jar
• proj1-{version}-stubs.jar

The file that is deployed:

• proj1-{version}.jar

Pattern for filenames (for each classifier, when classifier(s) provided):
"{projectInfo.name}-{version}{'-' + classifier}.{artifactoryConfig.artifactType}"

Pattern for filename when classifiers not provided (existing logic):
"{projectInfo.name}-{version}.{artifactoryConfig.artifactType}"

See https://github.com/homedepot/flow/blob/master/flow/artifactstorage/artifactory/artifactory.py#L126-L127

It is currently,

        except requests.ConnectionError:
            commons.print_msg(Artifactory.clazz, method, "Request to Artifactory timed out.", "ERROR")
            exit(1)

But this will inform the user Request to Artifactory timed out. for ANY ConnectionError exception which can mislead on what the actual cause is.

We probably want to change it to something like,

        except requests.ConnectionError as e:
            error = str(e)
            commons.print_msg(Artifactory.clazz, method, "Request to Artifactory raised a ConnectionError: " + error, "ERROR")
            exit(1)

Currently, custom message lose the markdown syntax when posting to Slack.

Currently flow sonar takes projectKey and projectName from buildConfig.json and allows projectVersion can be passed as param. We used projectVersion parameter for feature branch scanning. But recent changes to Sonar does not support projectVersion any more . So we are not able to scan for feature branch. We can still use flow if it allows to override projectKey and projectName via param. So when feature branch is scanning we will set key and name to append feature branch with repo name